If you’re seeing something with 64-bit, it’s definitely a separate underlying issue that we’d need a case with reproduction steps for.
I’m debugging some very complicated code, and for a while I thought my code was just malfunctioning. Then I realized that, no, some breakpoints were not being honored.
It seems like it’s some combination of the following factors:
- setting a breakpoint in the debugger tab vs. in another tab
- setting a breakpoint in the debugger tab in the current stack frame vs. a stack frame higher up
- (possibly) while debugging, editing some code then setting a breakpoint in that newly edited method - oddly, this often works in older versions of Xojo (my hunch is that if you set the breakpoint on a line above the line you edited, it still works - magically). Perhaps this has changed?
I’ll see if I can come up with a reproducible set of steps.
Please see this thread too.
If you watch the example video I posted in <https://xojo.com/issue/51969>, you will see that the only place where the debugger does not miss a next step is when it is not showing the details of a variable (that does not go out of scope in between).
I dont know if both phenomena are connected but they look similar to me at least.
The project is a (debug) build for 64 bit macOS currently.
Also for me breakpoints don’t work on my Mac OS Hight Sierra. Great disaster. Now i’m working with 2017r3. I think debugger is not so confortable to use because i spent more time to navigate around objects for searching the variable and there is not a comand line to inquiry directly the value of the variable (like Visual Basic).
I cant begin to guess how many times this has come up.
It would be SO useful, especially when trying to see which variable was ACTUALLY nil, or the value of a global variable while in a local method.
But…
I’m getting this problem as well. It’s not just a 32bit problem. I’m converting my apps to 64bit as I go, although they were all created in 32bit (I’m running High Sierra and Xojo R2018V1). If you add a BREAK command in the code then it works as do any other lines tagged with the break line tag. Remove the BREAK command and the line tags stop working.
Jack
Actually I’ve been seeing breakpoints fail to fire under 2017r3 for some time now, and I think I may have posted about it here previously. Code that I am 100% sure is executing cannot be breakpointed on. I can set a breakpoint prior to the point in question and then step through to it, and breakpoints elsewhere in the same method may work, but some places in the code just can’t be breakpointed on. Unfortunately trying to make a simple reproducible case would be a project in itself that I don’t have time for - that’s the job of the people who sell this software.
Running under MacOS 10.13.3.
Definitely having trouble with breakpoints in 2018r1 on Mac - 32 bit project. For example it’s missing a breakpoint set in the action event of a push button where there are only 2 lines of code. Closed project and re-opened, based on above suggestion - no luck. This makes my effort to debug comm issues very difficult. I rolled it back to 2017r3 and same breakpoints work fine.
My project was not stopping at breakpoints. Changed to 64 bit and now it stops.
Kinda sucks having just purchased this again.
dear xojo team…
do you have softwaretester or are we developer testing for you???
come on, it’s such an essential thing to use the debugger and its YOUR PART to test these things for all platforms.
every xojo-update is a desaster, i thought xojo became a professional tool
Dear Mathias…
2018r1 seems to have gone out a bit too early (with Debugging in mind / too late with release date in mind / and I guess they wanted to have something out before XDC)… but it probably works for 80% of their customers.
Since you’re a Pre-Release Tester: You know that a Point-Release is on it’s way. Are you still having issues with the latest PreRelease version?
If no… use it and look forward.
i use the official 2018r1. i’am not aware, that i use a preRelease…i have to use xojo productive, so i wouldn’t use a preRelease
and yes, i have to go back to 2017r3, but that isn’t the first time i have to use the older versions again, and many times there were big problems to go back to an old version, especially when u notice the IDE bug weeks later
it is just the frustration that growing up in 11 years using Realbasic / Xojo…and everytime the same kind of failures / bugs are annoying me.
just my 2 cents…and to finish my thoughts: it’s still an hateLOVE 
You obviously don’t - that’s why you’re having issues with BreakPoints in 2018r1 
The status of your Forum Posts say that you have access to PreReleases. That’s why I suggested to trying the latest PreRelease version… as this is what you’re going to have to use once it’s final. If that still doesn’t work for you - then I’d “complain” in that channel.
ok, than i’am sorry for posting in the false channel…but it doesn’t change the state of the fact that an official release have such monsterbug since 4 weeks
Breakpoints have been working inconsistently for me in 2018r1 running on Windows 7. Once they started working again after restarting Xojo, but most recently they didn’t so I went back to 2017r3 where breakpoints work reliably.
Did you tried Xojo 2018r1.1 ?
I didn’t know there was a new version. I got it and it did stop at the first breakpoint I tested, but then 2018r1 did also when I tried it again this morning. I would have to be using 1.1 for a few days to be confident the problem was fixed.
2018 R1.1 was released to fix a few major issues in 2018 R1, among them the breakpoint issue. As a beta tester, perhaps you may want to visit the pre-release section from time to time and why not, help with beta testing to avoid such issues in the next releases?
https://forum.xojo.com/47909-xojo-2018-release-1-1-now-available
Two weeks ago.
And I do not gave the Conversations links about that update.