If I make a change in Method_A, then make a change in Method_B, then return to Method_A to undo its last change, the change in Method_B gets undone instead. There is no visual cue that a change was made in Method_B. This is bad, or at least being unaware of this is bad.
In a word processing document, making a change at the top, scrolling to the bottom and making a change, then scrolling back to the top and performing an undo is expected to undo the change at the bottom and the changed section scrolls back into view to confirm the change.
Of course, when working between two word processing documents the undo is always performed in the document being edited.
So, is Xojo to be thought of as editing one long source code document, or as editing a series of documents that get assembled into the source code? (either way, a visual of the undo would be extremely helpful)
What you describe is an issue I stumble upon from time to time too.
Yes, you can consider a Xojo document one big file (which physically might be split into parts like when using the project format), and IMHO editor should indeed jump back to an undoed piece of code but seldom does.
Years ago there were plans for an IDE update. Maybe when this is done (if it’s still planned), undo will be fixed too.
Unfortunately, the behavior you describe is completely normal for the Xojo IDE. Even under Windows.
And it’s not limited to certain areas. Change code wherever you want, but when you undo those changes you can’t rely on the IDE to show you what you just undid. Sometimes it works, sometimes it doesn’t…
