List all Custom Properties in a stack

[jacque]

I believe the documentation for conditional breakpoints is explained in the user guide, but I haven't looked in years. Conditional breakpoints have been available for a long time.

The state of the breakpoints are indicated in the Breakpoints pane of the variable watcher at the bottom of the editor. I use them frequently because they keep my script clean of debugging clutter and I don't need to remember to remove anything before distributing a stack. Clearing all breakpoints from the menu item is all I need to do.

I also use in-line conditionals, but only for those cases where a problem occurs frequently in the same place in complex handlers. But for one-off issues the red dots are quick, convenient, and automatically temporary.

[dunbarx]

Jacque.

It was the ability to set a conditional via a red dot that was the news for me.

Craig

[marksmithhfx]

The state of the breakpoints are indicated in the Breakpoints pane of the variable watcher at the bottom of the editor. I use them frequently because they keep my script clean of debugging clutter and I don't need to remember to remove anything before distributing a stack. Clearing all breakpoints from the menu item is all I need to do.

Hi Jacque, I just posted a "possible bug" related to clearing a breakpoint (https://quality.livecode.com/show_bug.cgi?id=23940). The user guide I checked did not have complete information on setting conditional red dot breakpoints. There is this, but I was not able to find any discussion of conditional red-dots:

To activate the debugger, first ensure that Script Debug Mode is turned on in the Development menu. Then open up the script you want to debug and click in the gray bar to the left of the line where you want to open the debugger. Alternatively you can write the command breakPoint into the script. Using the breakPoint command allows you to break conditionally – if tVar is true then breakPoint.

Mark

[jacque]

I just posted a "possible bug" related to clearing a breakpoint (https://quality.livecode.com/show_bug.cgi?id=23940). The user guide I checked did not have complete information on setting conditional red dot breakpoints.

Good catch. There have been various issues with the Breakpoints pane in the past, looks like you found another one. I also just searched the User Guide and couldn't find a reference to conditional red dots, so now I'm not sure where I heard about it. I only know I've been using them for many years.

The lack of documentation might be a good candidate for another QCC report.

[bobcole]

Jacque.
It was the ability to set a conditional via a red dot that was the news for me.
Craig

Me too. After 14 years of playing with Revolution/LiveCode I am happy to know about Conditional Breakpoints.
I think this capability will help me with debugging.
Thanks Jacque,
Bob

[jacque]

For me I can comment out a "breakpoint" and still have a "breadcrumb" that says "this was a tricky part to get right" (usually I am using breakpoints or their alternatives at a point in the program where the expected result is not happening!!!). When you uncheck the red dot that history is lost.

Since we're talking about this, you can disable a red dot breakpoint in the Breakpoint pane of the variable warcher. That leaves it in place but it won't break into the debugger until you enable it again. It's another way to track your debugging history.

[bobcole]

by Jacque:
...you can disable a red dot breakpoint in the Breakpoint pane of the variable warcher. That leaves it in place but it won't break into the debugger until you enable it again.

I wonder how many times over 14 years that I have simply overlooked the Breakpoints pane.
Thanks Jacque for pointing out this capability of LiveCode's Editor.
Much appreciated,
Bob

[stam]

I think i had seen this feature before but if i ever (rarely) need to use conditional breakpoints, i'll usually add this to to the script as it's obvious.

One of the issues with editing the 'red dot' is that there is no visual feedback that the breakpoint has been changed to a conditional breakpoint... it would be better if it used a different colour or something to denote it's a conditional breakpoint.

On the other hand, putting it in the script makes it both obvious and easy to enable/disable but just uncommenting/commenting, without having to go to dialog boxes etc...

S.

[dunbarx]

Stam.

I earlier on recommended yellow

Craig

[stam]

I earlier on recommended yellow

I vote for deep purple

Joking aside, traditionally yellow is used for 'warnings' in IDEs for other languages - these don't exist in the current LC IDE but i'm under the impression these may be coming in the new one (or I may have misunderstood...)