I spent an hour trying to figure out why a calculation was wrong. I was stepping through the code and everywhere that it calculated the result, it was correct. But once I finished stepping through the code, the value on the window was incorrect. How was this possible?
Because I had forgotten something about debugging that is easy to overlook. When you step over a line of code that causes an event to execute, the debugger does not step into that event. It just executes it.
For example, say you have a TextField that has code in its TextChanged event. You are stepping through code using the Step button. You reach the following line: TextField1.Text = “Foo”. That is going to cause the TextField’s TextChanged event to execute but the debugger doesn’t step into it because you pressed Step rather than Step In. Thus there’s code executing you are not seeing in the debugger.
So just be aware that if a line causes an event to execute and you want to step through that event as well, make sure to use Step In.
Put another way, if you want to be sure that you are seeing EVERY line of code that executes, always press Step In rather than Step.
I always think of the “Step” button as “Step Over”, which is how it’s labeled in most MCU IDE’s I’ve used, and indeed what its icon conveys. What Xojo calls “Step In” is just “Step” in my mind.
It would also help if the debugger wasn’t a snowflake. I can’t count on how often I was stepping deep into some code just to have the debugger crash. Unfortunately, the crashes never are reproducible.
You need to add a long-missed debugging feature: break when a variable changes.
You can simulate this by converting that variable into a computed variable, and adding a breakpoint in the SET method.
Then, event or not, if the value changes, you know immediately, and you can see why from the stack.
After debugging is complete, I usually convert back again (not as easy as it could be) because the get/set methods do add an overhead to variables accessed in a tight loop.
I also submitted a request to be able to pin items to follow in the debugger. I hate it that I have a couple of listboxes on a window and some properties on another window and some variables, and when I have a breakpoint, I have to navigate all over the place to see how they’ve changed. I feel like Xojo hates programmers sometimes.
Do they throw away feature requests? Issue #1095 it says was submitted 9 months ago. But this is something I voted for back in the RealBasic forums like 20 years ago.
I’ve occasionally got the same feeling. My guess is, it has to do with various changes in how bug reports were stored (the Issues tracker of now is only a few years old; the system has already changed at least twice). We can also recall, at a given time, they had to import every bug report to the “new” system (IIRC, it was in the RealStudio period). In the current system, we can see there are weird-formatted reports that come from this transition (where headers are part of the core description and other items are mangled). In the end, it’s fairly possible dates are of the time of the import.
