Some of my projects have methods with very similar code, and there have been several times, while editing, that I have accidentally made changes to the wrong method, thinking that I was working on a different one. I wouldn’t discover what I’d done until running the code and then discovering the mess, and then having to recover the original code from a backup and start over.
It would be useful to be able to lock methods that I’m not currently working on so that I wouldn’t be able to modify them inadvertently.
Anyone else run into this problem, or am I the only one?
BTW, the reason why this keeps happening to me is that Xojo’s search function always wants to default back to the entire project, even after I’ve set it search only the current method. I’ll click on one of the search results thinking that it’s taking me to a line in the current method, when it’s actually going to one of the other ones.
When I want to make a lot of changes to an existing method, I’ll duplicate it so that I can work on one copy and have the other one as backup. If the changes don’t work out, I just delete the new method, and go back to using the previous one. I find this a lot easier than reverting an entire project. In one project, I may have several duplicated methods at any given time. If I could make the original copies read-only, it would save a lot of headaches.
I have two method to address this : one is to prefix the backup method name with “zzzz”, this way it comes to the end of the list of methods and it’s difficult to see them.
the other is to copy the content of the method to a note, this way it’s obvious to see you’re at the wrong place.
This was one of my first requests when I started with Xojo back in 2013.
What I now sometimes do is encrypt the methode with a two character password. Disadvantage is that if you need to look into it’s code for some reason, you need to open it again and still are at risk of changing something accidently.
Anyway, I would love to see a simple and quick “Read only” marker in the IDE, same like you @Robert_Weaver
Better use Git. If you have to alter a function, create a branch, change the originial method until it is perfect, then merge the branch into the master. You’ll keep a backup in your commit history and your methods are always up to date.
If you have several similar functions in production, better merge them together and make them abstract, so that one function suits to all usecases. Use parameter or the processed data to determine which sub-functionality is currently used. You can use SELECT...CASE, overloaded methods or code which is nested in multiple modules.
With this it should be much easier to keep your methods and your project tidy. And whenever you accidentially changed a method, go back in your Git commit history and grab the old code. Much better than using only backups.
Git may be fine for a software project being developed by a software team, but for one person, it’s overkill, and a big learning curve and a lot of overhead that I can do without.
As for the similar methods, I explained above that they are only temporary, so there is no benefit for code sharing. The eventual project will have the similar methods removed.
In this case, I always comment out all code in the backup/reference method. Makes it pretty easy to differentiate the new vs old code. There’s aven a keyboard shortcut to comment all selected lines. command-’ on macOS
this more a thing of a project or code management software, not a typical IDE.
Xojo is not responsible for if someone is not able to get its code managed.
And: for old methods you can still use the “deprecated” attribute.
I use Cornerstone, which uses subversion internally. Perhaps there is a way to make a branch, but I haven’t learnt how to do that, and I’m not going to try, in case some innocuous-looking command turns out to translate into rm -rf * internally.
If I want to mess with a method in a fundamental way, I usually duplicate it, and rename the duplicate as myfuncOLD. Then just experiment with the method and once it looks right, convert calls to it. Eventually the myfuncOLD just gets deleted.
I guess at some point I’ll have a look a version control tools, but for now I have my Mac backed up constantly with Time Machine, and that has worked well for recovering from serious blunders.
Jim McKay’s suggestion of commenting out the code after duplicating the method is easy and there’s no possibility that I’ll mistake the duplicate for anything else.
