Write protect methods in the IDE

I don’t know if this is a crazy idea or not, but…

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.

2 Likes

That the search defaults to global gets on my nerves, too.

Why do you have very similar code? Can you refactor the code so that you have sub-methods with the identical code?

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.

2 Likes

it would still be a good idea to have a way to write protect the methods, the same as we have for the controlitems in a window.

2 Likes

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

4 Likes

Don’t do something like this.

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.

1 Like

feedback://showreport?report_id=45578

4 Likes

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.

2 Likes

a toggle between note/method and a change protection would be fine.
a protection could act as ready/finished/tested.

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

4 Likes

You might copy the old method to an external module. Make the module on disk read-only and the IDE won’t let you modify it.

SVN is as easy to use as creating a repository and checking your code out. There isn’t much of a learning curve.

1 Like

that is actually not true.

If you use GithubDesktop for instance, then you have a simple 2-button-Git-Interface, but you profit from the full Git workflow.

I set up a Git repo for almost every little application I write, just to not care about data loss or accidentially overwritten stuff.

1 Like

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.

it is not typical for a editor but the usefulness is there from my daily experience at bigger projects.
i skip explanations.

Best idea I’ve seen so far. Quick and easy. Thanks Jim.

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.

And that’s actually where the OP’s question comes from :wink: