LiveCode Forums.

1. set a breakpoint
2. run/browse until the breakpoint is reached
3. resize the code window to attempt to see more variables

It appears as if after step 3 the breakpoint is skipped even if I haven't stepped past it. If the stack broke on its own, i.e. on an error, then resizing causes what appears to be an error reporter window to appear, and execution halts.

Is this a known issue? If it isn't how can I make it known? I can't imagine this is the anticipated behavior.

I can't imagine it is either. Check out the trial version of PowerDebug on revOnline and see if it fixes things up for you.

Yes, PowerDebug's Code/Variable splitter does not suffer from this issue. Perhaps that means the solution for the RunRev folks is buried somewhere in the PowerDebug code.

I'd like to use PowerDebug, but some of the interface choices make it difficult (and I can shoot them to you privately if you'd like).

Hi David,

sometimes the breakpoint by clicking the line and the red dot appears is not reliable. Just put a "breakpoint" into you code on a line by itself. That does not suffer from what you see.

By the way I like Mark's PowerDebug a lot. But I also use the built-in debugger.

Kind regards

Bernd

My breakpoint is stable when I resize the code window. Also when I resize the editor window itself.

V4.5 Mac OS 10.4.11

I would hate to have to add an actual breakpoint line instead of being able to click on the sidebar.

Craig Newman

bn wrote: By the way I like Mark's PowerDebug a lot. But I also use the built-in debugger.

I do too, didn't mean to suggest otherwise, but I'd like to like it even more.

dunbarx wrote:My breakpoint is stable when I resize the code window. Also when I resize the editor window itself.

V4.5 Mac OS 10.4.11

Hmm... v4.6.1, OS X 10.6.7

I do too, didn't mean to suggest otherwise, but I'd like to like it even more.

fire away. I'm always open to suggestions, but I'm not about to separate the debugger and variable watcher into separate windows for a number of reasons, if that's where you're heading.

I would hate to have to add an actual breakpoint line instead of being able to click on the sidebar.

I agree, but you wouldn't believe the problems you can get into when your breakpoints get out of sync with the code editor.

mwieder wrote: fire away. I'm always open to suggestions, but I'm not about to separate the debugger and variable watcher into separate windows for a number of reasons, if that's where you're heading.

Nope.

I was thinking more about how the step buttons are much too small for easy use (or at least my easy use).

And, some combination of LC editor color settings didn't play well with the PD color schemes especially the 'current line' highlight, but I've changed something I don't remember, and it's not showing the same hard-to-read-ness as it was originally.

I was thinking more about how the step buttons are much too small for easy use (or at least my easy use).

Yeah, and the text associated with them is small. Screen real estate is a problem. Luckily there are keyboard equivalents for all those buttons. Check the help box for details (yeah, I know, *another* small button...)

especially the 'current line' highlight

Lemme check into that again... I thought I was picking up the highlight color from the script editor. It does work that way if you're using the glx2 script editor, and I might have missed something in the code.

...after looking into things...

The buttons are about as big as they can get without running into each other. The only thing I could do would be to make the text uppercase. Er... you do realize that you can click on the text as well as the little icon, right?

...and...

I now remember why I'm not picking up the default highlight color from the IDE's script editor. There's a long-standing platform-independent bug where a query of the highlight color will be returned as "white" if it's empty. And making the highlight color white isn't very rewarding. So I could fake it and just make it gray if it says it's white, but that would get me into trouble if someone really had a white highlight on a gray background. So I just pick a color. You can change the color theme from the configuration menu if you like, and that should override the default theme.

mwieder wrote:...after looking into things...

The buttons are about as big as they can get without running into each other. The only thing I could do would be to make the text uppercase. Er... you do realize that you can click on the text as well as the little icon, right?

...and...

I now remember why I'm not picking up the default highlight color from the IDE's script editor. There's a long-standing platform-independent bug where a query of the highlight color will be returned as "white" if it's empty. And making the highlight color white isn't very rewarding. So I could fake it and just make it gray if it says it's white, but that would get me into trouble if someone really had a white highlight on a gray background. So I just pick a color. You can change the color theme from the configuration menu if you like, and that should override the default theme.

1. Yeah, it's just that the hit area is so short it takes more concentration than I'd like to get the cursor there. The mouseover change helps, but it's still an awfully small target. The buttons seem to be about 20 pixels tall, and even another 10 would be welcome, and not remove a substantial amount of real estate from the other components. Of course, I'm on a 1440x990 laptop, so perhaps they are better for other users.

2. Understood, and I can't remember how I had it set before (what combination of LC editor settings and PD settings), but something about my other settings had the highlight color different than it is now. I think it may have had a gradient applied a la iTunes. It's not like that now, and is much easier to look at.

I just released a new PowerDebug version, and one of the changes was to make the entire button area in the toolbar highlight on mouseEnter. I didn't make the icons themselves any bigger (well, I did, but I didn't like my first attempt), but now it's much more apparent what you're about to click on. Try the trial version on revOnline and see if that's any easier on your eyes.

Doesn't matter.

Just saw the announcement on the mailing list, and 'remote debugging' is enough to make the tiny icons not matter (as much, it would still be nice to have them bigger ).