Xojo does not stop at a breakpoint

Getting Started
1

Hello,
I set up a breakpoint before a calculation but Xojo ignores it and goes right to the end of the procedure.
It behaves like no breakpoint is showing.
I trie to save the project and even close it and restart but always with the same result. I cannot check the variables.
Anybody experiences the same problem?

2

I have, and I can’t reproduce it in new projects. I get around it by adding a “junk” line of code before it. Sometimes that makes the breakpoint work, and sometimes I need to move the breakpoint to that junk line. Super obnoxious bug.

3

Try clearing the caches through Preferences. But Bill is right, an annoying bug that’s hard to reproduce.

4

Try removing the breakpoint and replacing it with a Break instruction just as you enter the method and step through from there. I, too, have sometimes had breakpoints missed.

5

The problem with a break statement is that you can’t turn it off at runtime. :confused:

6

this days i had this phenomenon that i set a breakpoint at a var definition and this breakpoint was ignored.
so i just put them at other place in the method.

if condition then break ?

7

The IDE will let you set a breakpoint on things like an ELSE statement and then never break there. Make sure you’re not doing that.

8

[quote=490560:@Markus Rauch]this days i had this phenomenon that i set a breakpoint at a var definition and this breakpoint was ignored.
so i just put them at other place in the method.

if condition then break ?[/quote]
I think what Kem is referring to is that under the Project menu you can elect to turn off or ignore all breakpoints. That doesn’t work with Break statements. Those you have to either comment out or remove them manually (and individually).

9

That’s true, but I meant that you can set a breakpoint, or remove it, while the code is running.

In keeping with that, I will often include code like this, usually in a loop before the variable goes out of scope.

#if DebugBuild
  x = x // A place to break
#endif
10

This. +1

11

Yes, a breakpoint at the beginning of the code is a good idea. (before any code). If it does not fire, check before the caling code.

Nota: usually, I add a Beep and set the breakpoint to it :wink:

12

Just one line:

#If DebugBuild Then Break

13

it works also with a global flag which you can set via menu or button.
its useful if the app need to run awhile.

If DebugMode Then Break

or if you had a odd value you can stop at this malefactor for example in loops.

If v = "" Then Break

a extra menu for “ignore all break statements” would be nice.

14

On Windows the Break command is ignored in a built application and for debugging I can simply press the resume button to continue. Is that not the same on other OS’s?

15

It is.

16

As

#If DebugBuild Then Break

Is a compile time directive, no bytes, no call to some stub debugger should be generated at build time.

Not sure if a lost “break” does not emit any code when building, like a call to an empty subroutine with just a return, a debugger empty stub as no debugger is present at that entry point.

17

Thanks everybody. I’ll try some tricks