Simply closing feedback cases without any explanation

I feel the same as @Emile_Schwarz does. :pleading_face:
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:
Case 63259 I think that stopped working with 2019r2 too.


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.

  1. Easy/cheap - add a modifier key to override a feature (add a visual indicator if you’re feeling extra generous)
  2. 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… :confused:


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…


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 :frowning: ).

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.


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.

You can request a Feedback Case be reopened by clicking its Status:


Does that even work?

Technically, yes. Practically… it might as well be a black hole.


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)


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 :smile: .

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.