[dev build] $DEBUG mode ✨ Step through your code, watch variables! 🤩

[SMcNeill]

Both lines are empty, good friend. Set breakpoints to lines with actual code.

Does a line with just a remark, or a label, work as a valid breakpoint?

[FellippeHeitor]

Nope. Needs to be an executable line.

[RhoSigma]

Can the debugger not simply set the breakpoint to the next/prev valid instruction, if the user set it on an invalid/empty line? - Would probably avoid a lot of similar "I've an issue" problem discussions like the one you had with dimster.

[FellippeHeitor]

The debugger accepts the breakpoint being set to whatever line you instruct it to, it just won’t break cause such lines will never be reached. It’ll eventually be the case people will complain a breakpoint on an executable line won’t stop, and that’ll simply be due to their program flow never reaching that line. One can only failproof so much.

[Dimster]

Not quite sure I understand how to set a breakpoint. What I was doing is going to the line number where I want the break to occur. I left click on my mouse and that line number lights up in red. I then go to the next line where I want a break to occur and again left click on my mouse and again it lights up in red. When I scan the coding both line numbers remain in red. I am not sure why the copy of my code I sent to you did not show line #50 in red and line #160 in red.

Is that not how to set a break point in Debug? If you set break points in the code that I sent you did the program run and stop at the set break? Thought I was doing it correctly because when I use the option "Clear Break Points" in Debug menu those red lit line do return to normal line numbers.

[FellippeHeitor]

You set breakpoints to lines by clicking the line number to the left of the line, or by hitting f9 while the cursor is on a line.

Lines 50 and 160 contain NO CODE in the file you sent. That’s the problem.

[Dimster]

Fell - all these many years of messing with Break Points I had not realized there had to be code on the line where you wanted the break. I've gone back and reread the Qbasic books I have and none of them specifically state that there has to be code on the line to effect the breaking. The coding I write have so many lines of code I deliberately try to avoid empty lines so my breaks were on lines with code by sheer luck.

Son of gun, I just assumed a running program read every line of code and should have read the line had a stop on it.

Old dog, new trick. Thanks Fell

[Dimster]

I have a few variables which carry a decimal point in them (ie A1 = 10,  A1.2 = A1*.02) The Watch List displays A1 and it's value ok, but that A1.2 displays using ASCII. The value for A1.2 is fine and displays the correct values.

Is that ASCII display of a decimal pointed variable meant to distinguish it from an Array index?

[FellippeHeitor]

Please share the relevant DIM line and a screenshot with what you're reporting if you can.

[Dimster]

Here is the Watch List with ASCII

[FellippeHeitor]

Ok, I think I see what could be causing it. Thank you for reporting.

[Dimster]

Hello Fell - I have another head scratcher. Here are two screen shots where I have run the same test code. The first time I ran it everything froze up and I had to close it all down. What I did notice about this situation is a solid white square which I think is the cursor. You can see it in the Watch List about 3/4 of the way down the Watch List display.

After running the same code again, everything worked fine. This time however there was a flashing cursor in the Watch List display. I have tried a couple of times to capture the flashing cursor expecting to show you the cursor's position which is just under the last line printed in the Watch List and not 3/4 of the way down the Watch List display.

It seems I did caused the Freeze up. When the debug option to "start paused" is selected, the Watch List is behind the IDE screen. In my case I have the IDE width at 120 so I only get a sliver of the Watch List peeking out from under the IDE screen. If I right click on the BLACK of that Watch List everything is ok, but should you right click on the WHITE board of the Watch List everything  goes haywire.

Is there a way to have the Watch List open first on top of the IDE screen?

[FellippeHeitor]

In Windows, if you click a console window, it'll start "select" mode - which you can confirm by checking the title of the console window. Just hit ESC and Windows returns control to the running program (in this case, the IDE).

Is there a way to have the Watch List open first on top of the IDE screen?

You will just have to alt+tab your way until the console window is frontmost, then move it as one would.

[FellippeHeitor]

Latest development build available today contains the following new features/tweaks:

- Supports watching arrays with multiple dimensions. Friendly reminder that watching too many variables/array indexes will considerably slow things down.
- Supports changing values of individual indexes in multi-dimension arrays.
- Fixes the display of variables with "." in their names (which are not UDTs).

Known issue:
- Cannot set values of _BIT variables.

Let me know if you find issues. Thank you all who have been beta testing the new feature. ❤️

[Richard]

@FellippeHeitor

dev ee96ff7 Win10 x64 Pro build 20H1 aug updated

Not really an issue or problem for me - but every time I download a new dev build, I immediately use the previous build config.ini (because it is set up for font size (since on my Q3 display everything comes up half-size) and I need the high DPI setting for my applications), IDE color scheme etc.

However recently I notice that every time I have another instance of QB64 newly running - I have to redefine IDE (eg colors) as it appears to use your default IDE settings for [IDE COLOR SETTINGS...] even though all of them (including Scheme ID=0) are defined the way I want them.

As I said - it is not an issue - just that I have not noticed this before