Using Mac 2024 4.1. The IDE has been running probably for a week or so with the project open. I also had a number of other projects open.
It seemed like “run” was working well, however I went to a portion of code that is supposed to load some data from a file. It was not calling that method. It was literally jumping into another method not even related!
I spent a short time debugging this without getting to a root cause. So I terminated, the IDE, restarted, reloaded the project. This time run build what seemed to be a few more files and it worked as expected.
This leads me to believe that somehow Xojo’s internal list of what files need to be recompiled got messed up. Makes me want to do full builds a little more often.
But then, I am in the habit of shutting down all my apps, manually running Time Machine, then powering down my Mac each evening. And starting from scratch each day.
Otherwise, in a typical day, I use 2024.4.1 and three other older versions of Xojo (for older projects) and often have multiple projects and versions open at the same time. No issues.
Edited to add: When I restart from scratch each day, it helps to sprinkle my code with things like the following:
I’ve seen something like this, rarely but all in all a couple of times. When Xojo stays open for a prolonged time (I rarely restart my Macs), sometimes it gets confused. In most cases the app I was developing didn’t even run as I got some error messages about my code that made no sense at all. This has happened with various versions over the last few years. Restarting Xojo helps.
I’ve noticed a couple of “oddities” like this too when keeping several projects open and just closing the Mac lid. Minor issues so I didn’t record them, just closed everything out, shutdown, and restarted, then all’s well. I close down regularly now.
Yep, definitely need to restart Xojo from time to time. I’ve had it just completely ignore code that I’ve written. Obvious things like a MessageBox for debugging. I think what happens is the compiler has cached some compiled bits and doesn’t recognize that it needs to recompile to catch the new code.
Xojo IDE is a Xojo app. That makes me fear about possible weird behaviors like that waiting to happen in apps we produce. I do remember conversations about speed improvements avoiding some tests and using cached values, this behavior matches bad behaviors tied to cases like using cached wrong values that should be refreshed and aren’t.
Well, I’ve been developing code for 45 years now. I am well aware that compilers and IDEs mess up. I just wondered if this was new behavior in the latest version and maybe the Xojo devs are interested.
On the shutdown restart, I guess I am used to my Mac being pretty solid for about 2-3 weeks. I dev in Windows C# for a living and yes, I restart that every morning and sometimes multiple times a day even.
Anyway good to hear (sort of) that I am not the only one.
Not to discount the multiple reports of this issue, but I’ve been using Xojo for a very long time and never encountered this - although I don’t spend as much time in it these days. Perhaps it’s an issue that has cropped up rather recently.
I’m certain that the Xojo engineers would be very, very interested if anybody could produce an example that they could somehow dissect. I think the challenge will be capturing the entire state of the system - the IDE, the cache, the code, the compiled app - in such a way that the issue can be identified and reproduced. Someone from Xojo should chime in here so we can get an idea of what they might require.
Ya Eric, that will be the problem. I suspect this was just related to having the IDE open with lots of projects open for like 2 weeks straight and something got messed up. If anyone from Xojo wants data I’ll show them what I can. I doubt I can create a small reproduce.
Just had this happen on the Windows version of Xojo. I replaced a window with a duplicate new version, and changed the Window.Show method in my main app to the updated NewWindow.Show.
It worked once, and then Xojo would show the old window until I restarted it.
Remember:
Xojo have its own Undo mechanism. So, using it without quit for a long time takes memory (IMHO), and that increase at each Cut / Copy / Paste.
Also, Xojo is subject to low memory conditions: works bonkers in low memory conditions.
I recall having modified the data I Copy in the Clipboard, and at Paste time in the .debug application, I get the old version, until a reboot.
All of this to say:
Power Off your computer after extensive work.
Avoid running concurent applications (many applications at the same time).
Don’t think “I have a M6, so I do not have to…” or “I have an i9SuperHyperPro, I do not have to…”.
They are computers, Power them off. Wait a minute (drink a cup of tea or coffee), and reboot / resume working.
That is what I learned using computers on these last 45 years.
I’d love to see an example of this. In my own experience with my own code, It has always been my fault. Forgetting to update casting code, or code that’s running from a super of the class where it seems obvious that the class was initialized as a foo but because it’s running in the context of the superclass bar the methods of bar take precedence.
There have also been issues throughout the years where the Xojo IDE wouldn’t apply a change entered into the Inspector if you didn’t click away in just the right way. This could easily lead to this kind of error if you think you’ve changed a super class when you really haven’t.
In my case, Eric, I had not changed the class that was calling the wrong thing. I had been working in a completely different area of the code. That is not to say it still could have been a change that was not applied correctly. But again, I exited the IDE, restarted, re-ran and it worked correctly.
From my knowledge of compiler technology, there are a lot of look up tables built when compiling to map variables, classes, superclasses, virtual and overridden methods etc. This feels alot like a look up table got changed and was not recreated because the file was not rebuilt. So I still suspect something triggered a change, but that file that contained the classes and calls was somehow not recompiled so the call was compiled in incorrectly. Totally a guess but years ago when we built our own IL compiler for our product we had similar issues at times.
Yes, this can happen when the code in question wasn’t even touched for quite some time, and it works just fine when I quit Xojo and start it again without making any changes to my project. So it is definitely no fault of my own (of which there are enough, but not in these cases) and the fact that simply restarting Xojo removes the problem proves it is a Xojo issue.
Having said that it doesn’t happen all that often and as the issue is easily resolved I’m not really worried. And I perfectly understand how difficult it must be to recreate that bug in order to solve it.
It’s worth pointing out that there are mechanisms built into Xojo that can cause the behavior you are describing. For instance, AddHandler redirects where code runs. An unbalanced call to AddHandler/removeHandler could certainly cause behavior changes like this too.
