Soft Breakpoints are too soft

[dunbarx]

This has come up here and there. I am forced to use the breakpoint command in-line, since soft ones do not reliably persist. So annoying. HC never suffered from this malaise.

Has this ever been addressed? I am in v.6.7.

Craig Newman

[FourthWorld]

I don't understand what you're asking about. Can you provide more details?

[dunbarx]

Richard.

Setting soft breakpoints oftentimes will not stop a running handler. They might for a few trials, but then execution will pass through as if they were not there at all. I have to place a "breakpoint" command in-line, which always works. But that is tedious, if one is simply fooling around with code testing and debugging.

This has been discussed before, I just could not find the threads, so I reposted. Somebody please tell me I am not the only one who has seen this. I can reliably duplicate the effect, but it never ocurred to me to submit a stack with such a condition. And I have never brought such a stack to another mahine to see if the problem carried over.

Craig

[Simon]

Yes, I've seen it.
the red dot gets ignored on occasion, post liveCode 5.5.

Simon

[SparkOut]

In every version of LiveCode that I have used (on Windows, since 2.7), sometimes the red dot location is not properly updated to stay with the line it was set to halt upon if the line number changes - probably, if I think about it, when cut / pasting code rather than typing. The "ghost" breakpoint dots survive in the margin through compilation, but will then not halt anything. I am struggling to remember a time that an intact breakpoint fails to halt. I think I have noticed it once or twice, but I may be inventing the thought rather than recalling it.

[dunbarx]

Sparkout.

Do you really mean the red dot moved? Or that is stopped execution at another line than the one originally set? Mine stay put, but they become ineffective. It is a matter convenience; it is simple and fast to set dots. It is time consuming to type the word "breakpoint".

Craig

[jacque]

I've seen the problem where the dots move or disable when line numbers change, but never when they stay put, with one exception. If a line calls into a rev library, the handler will sometimes run to completion after the library returns. The IDE does that to keep you out of its scripts.

You can change that by setting gRevDevelopment to true. But you will be dropped into a morass if you go there.

If this sounds like what's happening, the easiest fix is to bracket the call to the library with red dots.

[dunbarx]

Jacque.

Rarely calls to a rev library.

I am certain that I am oftentimes running the same code but with different data, likely derived from card attributes. And when I say I am certain, I mean I will watch, in the immediate future, to see if that is true. But if it is indeed true that the red dots do not stick with unchanged handlers, isn't that something that should cause insurrection? And shouldn't it even if the handlers do change?

Craig

[jacque]

If you can find a recipe then yes, the team should address it. But except for the cases I mentioned, I've never had a problem with dot breakpoints, so I'm not sure what you're seeing. I remember someone on the mailing list had issues but he didn't have a recipe either.