We are doing so much work for Xojo by finding bugs, reporting them (in a very poor feedback app which is slow, crashes several times a day, half of the features don’t work, isn’t intuitive …), making sample projects (because without them the cases are closed anyway) and so on.
Just that we don’t fix Xojo’s bugs ourselves.
So please @Greg_O_Lone give me an explanation WHY this is not a bug if I lock the position of a control and it can still be moved with the arrow keys.
EDIT:
This bug appeared somewhere between Xojo 2018r3 and Xojo 2019r2.
With Xojo 2018r3 and earlier it’s not possible to move the locked control.
With Xojo 2019r2 and later it is possible to move the locked control.
Because the behaviour is the intended one. I think it’s a very good behaviour. The locking protects against accidental moving. But yes, an explanation would be helpful.
I didn’t add an explanation because quite frankly it doesn’t add anything. We’ve been down this road before and regardless of whether we supply an explanation or not, someone’s not going to be happy about it.
I use a lot of different types of layout programs, both IDEs and graphic, and the vast majority of them perceive locking the way we do now. Yes it’s a change from the way we used to do it, no, it is not a bug.
In respect of your customer’s time input in making cases and providing you with the ease of finding a solution to a problem or feature. At least a comment added to (some) cases could be added to the closing to inform the creator of the case and others reading the case (even after it has been closed).
I totally agree with you.
A simple short statement like now in the forum would make such a huge different.
@Greg_O_Lone
It’s not about making everyone happy.
Simply closing cases without any explanation is so disrespectful and makes an impression that you simply just don’t care about our really time consuming efforts to report YOUR bugs and make YOUR product better.
Please tell me which different layout programs do you use and which one of them let’s you move controls with the arrow keys even if they are locked?
I guess there was also a reason why it was different until 2018r3?
The Lock Position button is used to lock controls so that they cannot be moved or deleted while editing the layout. You can use this feature to prevent your user interface from being accidentally changed while editing it.
Lock/Unlock Position
Locks the control at its position on the layout preventing it from being accidentally moved while editing the layout. To move the control, unlock it first.
Random “features” that contradict the documentation (it can be moved and deleted even locked ) and sarcastic answers when someone gives feedback about it.
Sorry to say that I have seen this lately more frequently than before. There is no explanation or request for more information as to why we think it is a bug.
Another example: <https://xojo.com/issue/63806> the behavior in Web 2.0 is different than Desktop and Web 1.0, so now, instead of a bug report, I opened a “feature request” hoping they can change the design to make it consistent across platforms: <https://xojo.com/issue/63816>
I have no clue what’s going on to be honest and probably neither does Xojo. Controls being deleted while locked happens with all editions I have installed all the way back to 2015. In 2016 <https://xojo.com/issue/21188> claimed to have introduced delete protection for locked controls but either that wasn’t tested or it never actually made it to release because in 2016r3 I can still delete locked controls so /shrug
It seems that the movement of controls with keys was stealth introduced here <https://xojo.com/issue/56485> probably as a side effect of another fix.
At the end of the day whether the justification for the change is because of “other apps doing it so shall we” or “the path of least resistance to get a feature fixed” is by the by as whatever they feel like doing gets done and we are just bystanders.
Yes a little one liner would have been nice in the close of the ticket to mention that the feature is how it is going forward and to put in a feature request for the change if its requested instead of just a blank close, k, thx, bai. However I’ve seen this happen enough to know that this is the answer in these situations, I just read it as “its how it is now, we don’t care if you don’t like it, make a feature request that can be ignored” and if its not something egregiously bad then I’ve got to the stage when I just don’t care to argue the case any more, sad that it is that it’s come to this, but /shrug
The problem stems from Xojo’s belief that the UI should be simple, while I agree to an extent for someone that is new to Xojo and/or programming to find things “easy”, I totally disagree that features should be removed or not added simply because they can clutter the UI.
Things like this which are clearly opinionated, where your/xojo’s opinion differs to that of your users should be moved to an advanced options section and the freedom to tweak these things should be retained and put back into the hands of those that want the old method.
Removing features or not implementing features because you lack space on your simple options interface is an extremely dated design ethos and is one of the many things that irk me about the IDE.
the tooltip said lock position so it do not have to move in any way.
i think a better option is to lock/protect the whole control with all his propertys.
if me delete a locked control by key does it change the position?
i not like this stubborn resistance, i think every user that give feedback mainly because its useful for all.
I got some informations from @Jason_Parsley that they talked about it internally and they suggested that moving would only be possible by holding down the option key.
What do you think about that?
On the one hand this would be a solution for all (those who like to move the control even if it is locked and those who think it should stay where it is) but on the other hand it doesn’t feel right somehow.
If I lock my car or my house door or my smartphone I have to unlock it to drive the car / get in the house / use my smartphone.
When was the current behaviour implemented? 12 to 18 months? So far nobody complained.
I’m happy with the current behaviour. I can get behind with moving with option pressed, too. Locking should protect against accidental moving. And the current behaviour is even better.
For over 20 years I have been using a Wacom tablet instead of a mouse. Since the beginning of Realbasic the controls sort of have wiggled around when trying to move them with the pen because the pen is so much more sensitive than the mouse. Now I can finally move controls around without having to move them back first.
Locking should lock. Not lock only in specific situations.
I’d prefer if lock would just lock. I don’t use the feature because it’s not working for me in it’s current form.
If no explanation is given, there’s no expectation the creator of the case is going to be happy (I, for one, would just be frustrated and avoid filling other cases).
If an explanation is given, at least I understand how my point of view doesn’t fit with the product. I may be angry after that (though I’m not someone easily angry myself), but either it’s because I feel I’m right (in this case, a discussion should be open) or because I’m obtuse (and that’s just my own problem that you should disregard). I’m saying “I” as “anyone”.
Filling cases isn’t straightforward: reproducing the problem in a simple project (often leading to strip down an existing project because the issue involve more than one fact) can be complicated or takes time. And they’re made to make your product better; isn’t that kind of us already?
If the feedback of my case is to close it without explanation or otherwise disregard it, of course I won’t easily make further cases and will try workarounds (which may include moving to other languages if the same behaviour happens too often, as anyone has a limit on frustration/anger).
And, when someone starts feeling reporting cases isn’t worth anymore, that person will have a poor experience (often amplified over time, seeing similar things at other places) and the product (both Xojo and users’ built apps) won’t progress.
Just imagine how you’d feel if you go to the bakery and the seller just says “No, please go home” instead of “No, sorry, I don’t have this bread anymore” (then leading to discussing if another bread is available).
) and sarcastic answers when someone gives feedback about it.