Note testWindow is hilited under the windows list and the double-quote is selected in the search field. I pressed fwd-delete to remove the dbl-quote and update the search. Guess what happens: the dbl-quote remains but the entire testWindow is deleted from the project. If you don’t notice this you will lose a big chunk of your project and wonder why suddenly your builds fail.
Curiously regular back-delete works as expected: the dbl-quote is deleted and search updated.
This can be seen very easily with a brand new, essentially empty, project. Such a project comes pre-loaded with a window. I observe (20201r2.1, Mojave) that if the window is selected in the navigation sidebar, then if any part of the Find text is highlighted, the window will be deleted by fwd-delete.
I’ve also had spurious object deletes when I wasn’t expecting it due to the focus appearing to be in one place but actually being in the navigator. Happened fast and I was more concerned with undoing the deletes than figuring out exactly how it happened. Seems to have been in the last few versions.
Disappointingly, this bug persists in the latest 2021r3.1 (and bit me again). I would’ve thought that given the severity it would’ve been addressed quickly.
not sure I understand Tim, the case says reproducible and the latest release still contains the bug, I realize Xojo has lots to do, but this is not a trivial issue IMHO.
Not all bugs are created equal. Is it serious? Yes. Is it affecting a lot of people? I doubt it.
Our team uses Xojo all day every day and no one has complained about it. We just use it differently than you do. I would also recommend that you use source code and version control (git, subversion) and use the text project format. This ultimately is your life preserver because when you commit early and often you can back out any changes, intentional or otherwise, any time you want. Git has saved my bacon more than once.
I’ve run into this issue myself in the past couple releases.
It was difficult to pin-point the problem at first (I thought it was me being inattentive), but I finally noticed the same behaviour described by Peter. Thankfully Cmd-Z works on macOS to undo the object delete, as long as I recognize what’s happening right away.
I’ve added some points to the case so now it’s ranked at 41st.
I suspect it’s due to a deeper issue with the IDE keeping track of the current control and text selection. I’ve run into this before, and it reminds me of a couple of other bugs. One is that sometimes you have to select a method/property/constant in a class in an open tab in order to be able to create new ones. Another is that sometimes I’ll start typing and be shocked at where the new text appears (i.e. I think I’m typing new code but I’m actually over-typing a value in a method or property field off to the right).
Sometimes it feels like the Xojo IDE just doesn’t know where I’m at, or where I expect commands to be directed, based on the feedback in the GUI (i.e. which tab is selected, where the cursor last appeared, what text or item is highlighted in blue).
There have been focus issues since the very beginning of the Xojo IDE. I believe it’s an inherit design flaw. Some will disagree but I much preferred the REALbasic IDE and even though tab management was kind of a pain you didn’t have the focus issues Xojo has.
At a minimum, in my opinion I’d say that if text is hilited in a field and you hit delete (fwd or back), the hilited text should be, well, deleted. I think everyone would expect this to happen. And like Daniel, I’ve also inadvertently overwritten function arguments when the cursor is flashing in the code editor and I expect my typing to appear there, and not be directed to the argument list (and as I recall, this one is not undoable, with cmd-Z actually undoing something else, possibly in another method’s source).
So I agree, Xojo’s IDE is occasionally dangerous and you must pay attention to changes that might be happening in places you don’t expect.
