I feel the same as @Emile_Schwarz does. 
I still report Beta Issues but stopped to report any other issues or feature requests since 2020/10ā¦
1 Like
I guess thatās why Robin closed Case 63973
Iām ok with the Option + Arrow and Shift + Option + Arrow to move locked controls.
I can do several things with my locked smartphone without unlocking it, take photos, answer calls, flashlight, etc.
Xojo has so many features that some are not used or known. For example:
https://documentation.xojo.com/topics/advanced_features/setting_default_values_for_xojo_framework_class_properties.html
Case 63259 I think that stopped working with 2019r2 too.
3 Likes
It is much better, make it the same for deleting them.
In my opinion I think its a bad idea and in my opinion the correct method would be to allow Lock Position to have its own keyboard shortcut to allow for easy lock/unlock, then keyboard users could unlock>move>lock without having to move the control with the mouse which can be a nightmare if its embedded or obscured in some way, I can appreciate where this feature was born from.
Doing it this way means that everyone knows what to expect, that locked controls can never be moved or deleted and any future system that hangs off the lock will also be covered and wonāt need additional coding and discussions like this to work around/fix. The more tweaks and edge cases that are added, the more possibility of something going wrong in the future where something is overlooked or not known about.
However now you have the whole issue of should the feature be added to the Edit menu for it to gain a shortcut through the Edit Shortcut system as thereās currently no way to shortcut certain things on the context menu or top toolbar (align, front, back etc.). āSet Default value ofā¦ā is on the Edit menu, why isnāt Lock Position as that would seem to be a common use feature? So do you go down the whole route of adding the top toolbar to the Edit Shortcut system so that all the buttons on there and can have shortcuts assigned to them?
Yes Xojo could put in ctrl/option + cursors as its probably something that is used internally quite often as its recently appeared as had no visible feature request for it or Xojo could do it properly and have the control actually lock.
But at the end of the day, all discussions aside, its a mater of cost/time vs feature impact vs public perception.
- Easy/cheap - add a modifier key to override a feature (add a visual indicator if youāre feeling extra generous)
- Costly/impressive - do it through the current shortcut system (only extra cost because of the time involved in doing it right the first time, all future changes like this will then be cheaper but will be equally as impressive).
I for example would expect that holding CTRL/OPTION and clicking + moving a control would create a duplicate of this controlā¦ 
2 Likes
Dear Xojo,
If I take the time and effort required to create a thoughtful and informed feedback case (be it a feature request or bug report) I expect to receive some recognition of my efforts. You donāt have to agree with me but if you want to continue this relationship, you should at least respond with an equal amount of thought and consideration.
Yours trulyā¦
9 Likes
I suggest the close of any case have just a one liner canned response like āwork as intendedā, ānot reproducibleā, ānot a bugā, things like that.
Then who submitted the rehhquest needs think a bit about it, maybe reword better things, maybe look twice at docs before saying all is broken, or complaining
In my own business Iām trying my best to always leave at least a short note why Iām closing a case. But we are all humans, sometimes I might just close it, especially when it is not clearly described or after a bad day etc, but it very rarely happens that someone will re-open the ticket and complain (which of course doesnāt mean that the client is happy, he or she might just have given up 
).
Not being able to re-open a ticket by answering to it after closure is the bit Iām missing the most. I want to thank someone if the issue is solved but I want as well to express my disagreement without having to write a new case. I really hope that the new Feedcase app will have such a functionality. In my own business I want to close tickets but I still want to get the feedback if the issue is indeed solved for my customer. My 2 cents.
1 Like
I think the process now would be to email customer support and make the case for re-opening the ticket.
But I agree that there should be a way to do that directly in Feedback.
2 Likes
Iād agree, but if you allow re-opening tickets by users, there will always be users insisting that their point of view is right and always re-opening cases without much correct sense.
There are also reports that clearly must be closed (like those concerning earlier IDE versions or no-longer applicable); what would re-opening them mean?
So do I. For thanking, perhaps the creator of the case could have a āResolved, thanksā button, useable only once?
And for disagreement, perhaps having a field where the creator of the case could write his/her thoughts (and asking the case to be evaluated again) would be feasible?
I fairly understand why a closed case shouldnāt be re-openable (or discussed, like a forumās thread) on demand, as then, no closed case would be definitively completed. On the other hand, having reports closed without having a chance to explain when the closer made a misunderstanding is also not good.
P.S.: I just realised something in this forum: if you remove the end of line before the /quote tag (e.g. to make more compact replies), the quote appears as plain text. Something to watch out, especially since itās often seen.
Does that even work?
Technically, yes. Practicallyā¦ it might as well be a black hole.
2 Likes
Upon selecting āReopen Caseā, you fill in a āReasonā and itās up to you to make the case that this should be reopened.
did it on multiple cases, they are still closedā¦ (even after years, no response)
2 Likes
Well, I canāt speak to their process once you request a case be reopened, only that the functionality exists.
1 Like
Waouww, I discover the Lock button with this post 
.
And I discover DarkMode button too. What a silly man, I build many time in debug mode to see what my apps looks like in DarkMode.
I will be more curious now.
Yes Iām agree, I think controls shouldnāt move when we hit arrows keys until we hold down Option key if locked.
When I select a control Iām always afraid of moving it 1 pixel. I would like to lock them all (now I know I can) and move only if we hold down Alt key (not only with arrows keys but mouse move too).
If the feedback wasnāt closed, I could add my comment there. Then what should I do, open another feedback request ?
Since option-dragging traditionally means āduplicate the dragged itemā, Iād be against the use of this particular key (since the behaviour should be consistent between moving with the mouse or with the keyboard). The control key (on Macs) is to show a contextual menu. And the shift key, IIRC, is already used in Xojo to increase the move speed (moving with the keyboardās arrows, of course). Also, the command key (as with the shift key using the mouse) is meant to select additional items.
As keys are already defined, a single modifier key would be confusing. So either have several keys involved (command+option, for instance) or, as others have suggested, a shortcut to temporarily disable/turn the lock (e.g. the F7 key).
1 Like
Be careful with compound keys + arrows, in some configurations, in special in some Windows boxes, it changes screen orientation ctrl+alt+arrows.
It seems to me that, in that context (a layout editor vs a code editor), the arrow key by itself is the temporary bypass for the lock. And I can see the convenience of that.
Where reasonable people differ, a Preference is in order.
3 Likes