IDE

With release 2018R4 we have the best IDE version since long time, according to my experience on Windows 10.
Although I am aware of a few issues that can cause the IDE crashing, I am happy with it now. Unfortunately it’s not always possible to reproduce crashes on demand, which can make it hard to get it fixed for the team.
For me, the quality the output without too much workaround programming is most important, but if I might just one IDE feature request which would give me a better feeling with large projects, it’s (https://xojo.com/issue/45578)]Feedback “45578 - Add the possibility to lock classes, methods, etc.” , raised by @Paul Sondervan back in 2016.
If you agree, please add your motivation to this case, which will raise the importance of this “forgotten” feature request.

With release of 2018r4 we have the best IDE version in a long time, and the worst. The “best” because there are a few minor features it contains (line number, auto format etc.) … but also the worst because the speed of operation is TERRIBLE. I am using 2018r4 on a 4.2ghz i7 iMac, and in one project the simple act of duplicating a control, and adjusting its position takes almost 30 seconds (mostly waiting for the cursor to move). On small simple projects its no big deal, and yet in the greater scheme of things, the project I am working on is not HUGE…(large yes, but not huge)

Ok @Dave S I understand your feeling, although I don’t experience this behavior myself on Windows.
But, to put the focus back to the point I would like to make, would you appreciate the locking feature-request as described in FB 45578 ?

[quote=418863:@Joost Rongen]Ok @Dave S I understand your feeling, although I don’t experience this behavior myself on Windows.
But, to put the focus back to the point I would like to make, would you appreciate the locking feature-request as described in FB 45578 ?[/quote]
Since feedback has never worked for me, I don’t know the details so am unable to comment, but if it involves the “tabs” in the IDE, then the answer would be “no”, since that is (to me) a useless feature. If it involves something else, then I can’t answer.

Have you tried the new version of feedback?

@Dave S
<https://xojo.com/issue/45578> has noting to do with “tabs”.

[quote]Many times we want to prevent created classes, methods, etc from unintentional changes.
It is possible to encrypt the class, but that makes the source unreadable.
Our idea is to add the possibility to lock a class, method, etc…
This will prevent unintentional changes while at the same time the source is still readable.

Although using version control, it is possible to make an unintentional change that isn’t noticed immediately.
Once the mistake is noticed, it can take a lot of searching in older versions to reverse the unintentional change.
Locking of classes, methods, etc. prevents them from unwanted changes.[/quote]

Something like this.

Nope, I give a software product usually once chance, in the case of feedback I wasted many hours.

@Dave S - you challenge me to tell a truth story:
“I once bought a nice looking software control from you, I gave it a second chance … unfortunately it went like Feedback at your side”.

Back on topic, I also think this would be a nice addition and have assigned some points to it.

On a Mac, if you have you code in a separate *.xojo_code file, you can lock that file in the finder to prevent any changes. The IDE will happily let you modify it, and there is no indicator that it’s locked, but at least the changes won’t be written back to disk.

Not sure about Windows or Linux, but I don’t see why it would be any different.

They both allow a similar locking mechanism (RO) and suffer from the same problem with the IDE.

[quote=419205:@Tanner Lee]Back on topic, I also think this would be a nice addition and have assigned some points to it.

On a Mac, if you have you code in a separate *.xojo_code file, you can lock that file in the finder to prevent any changes. The IDE will happily let you modify it, and there is no indicator that it’s locked, but at least the changes won’t be written back to disk.

Not sure about Windows or Linux, but I don’t see why it would be any different.[/quote]
This is both a blessing and a curse. I’ve lost plenty of code due to the IDE not confirming the code was actually written to disk.

Yeah, I was kind of surprised it didn’t throw an error. It’s not something I’d use day-to-day - would much prefer the locking mechanism proposed by @Joost Rongen.