Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD Breakpoints don't work on If's

C

CityguyUSA

Jan
179
2
I thought a breakpoint on the first line of an if statement would work but it doesn't. This also leads me to question For Do's or any statement with command groups. Breakpoints on labels don't work either. It becomes pretty easy to be unable to break the execution without these choices.
 
CityguyUSA said:
I thought a breakpoint on the first line of an if statement would work but it doesn't. This also leads me to question For Do's or any statement with command groups. Breakpoints on labels don't work either. It becomes pretty easy to be unable to break the execution without these choices.
Click to expand...

You cannot set a breakpoint inside an IF or a FOR statement (because it would break CMD.EXE compatibility). However, you can set a breakpoint on the first line of an IF or a FOR. (CMD considers any IF or FOR statement to be a single line command, regardless of how you format it in your batch file with line continuations or command groups.)

You can set a breakpoint inside an IFF or a DO or a SWITCH.

You cannot set a breakpoint on a label, because it is not a command and the parser never sees it. The GOTO or GOSUB command moves the execution pointer to the line following the label.
 
Consider using the BREAKPOINT command as an alternative to pressing F9 to toggle a breakpoint.

1780836306819.webp


If the batch debugger is not active,
BREAKPOINT is ignored.

Joe
 
rconn said:
You cannot set a breakpoint inside an IF or a FOR statement (because it would break CMD.EXE compatibility). However, you can set a breakpoint on the first line of an IF or a FOR. (CMD considers any IF or FOR statement to be a single line command, regardless of how you format it in your batch file with line continuations or command groups.)

You can set a breakpoint inside an IFF or a DO or a SWITCH.

You cannot set a breakpoint on a label, because it is not a command and the parser never sees it. The GOTO or GOSUB command moves the execution pointer to the line following the label.
Click to expand...
You can sert a breakpoint on the first line of an IF but it doesn't stop execution because when the debugger hits the IF it goes to the last line of the IF and it's like it doesn't see the breakpoint.

I had a call followed by a label followed by an if. If I set the breakpoint on the call I have to go through the execution of the call and I didn't want to do that. So next was the label which wouldn't break and then the if which also didn't break.
 
CityguyUSA said:
That sounds like an option but then you cannot set it on the fly.
Click to expand...
Are there other Debugger only commands? Like a GOTO that only works in the debugger and are ignored at all other times? I saw the ON which is more like an event trap and I'm not even sure if that's a debugger only thing.

What's a WAD?
 
WAD = Works As Documented.
 
rconn said:
You cannot set a breakpoint inside an IF or a FOR statement (because it would break CMD.EXE compatibility). However, you can set a breakpoint on the first line of an IF or a FOR. (CMD considers any IF or FOR statement to be a single line command, regardless of how you format it in your batch file with line continuations or command groups.)

You can set a breakpoint inside an IFF or a DO or a SWITCH.

You cannot set a breakpoint on a label, because it is not a command and the parser never sees it. The GOTO or GOSUB command moves the execution pointer to the line following the label.
Click to expand...
I didn't set a breakpoint inside an if. I set it on the FIRST line and I've done it again and again the debugger ignores it. This isn't WAD this is a BUG!
 
Joe Caverly said:
Consider using the BREAKPOINT command as an alternative to pressing F9 to toggle a breakpoint.

View attachment 5859

If the batch debugger is not active,
BREAKPOINT is ignored.

Joe
Click to expand...
Can these go inside an IF?

The inverse problem with these it will stop every time. I'd like to get a way to stop right after I return from a call or even at the end of the call I guess would work. I could put it in the called script which could be called from a command structure and get it to stop mid-If right?
 
Test with different values of a

Start with F5,
then Shift-F11 to run to Breakpoint.

1781050949281.webp


Joe
 
Here are some typed breakpoints that don't seem to break and another one this one that's misspelled for some reason.

Screenshot_20260610_185850_RVNC Viewer.webp


Missing breakpoint.

Screenshot_20260610_185932_RVNC Viewer.webp


Multiple missing breakpoints not even highlighted red.

Screenshot_20260610_185947_RVNC Viewer.webp


Breakpoints but won't break?

Screenshot_20260610_190021_RVNC Viewer.webp
 
Yet another issue with hard-coded breakpoints.

There are 4 hard-coded in the script. 2 are commented out. The debugger ran through the entire script without stopping at either of the 2 breakpoints not commented out which are not nested in anything. FIND didn't find a single one of the breakpoints.,

Screenshot_20260610_205706_RVNC Viewer.webp
 
CityguyUSA said:
Yet another issue with hard-coded breakpoints.

There are 4 hard-coded in the script. 2 are commented out. The debugger ran through the entire script without stopping at either of the 2 breakpoints not commented out which are not nested in anything. FIND didn't find a single one of the breakpoints.,

View attachment 5876
Click to expand...

The status line in your screen shot for the find issue shows your cursor on line 536 and the "wrap around" checkbox in the dialog is not selected. Are there any breakpoints beyond line 536? If not, then the find command will stop searching at the end of the file and not "wrap around" to continue the search from the beginning of the file.
 
CityguyUSA said:
Here is one of these random breakpoints that gets added.

View attachment 5870
Click to expand...


Here's one way that can happen.

If you click in the margin to set a breakpoint on say line 3 in your DriveBackup.cmd file. Then save the file. Then close the file. The Debugger will save your breakpoints in a file named DriveBackup.cmd.bp so that when you reopen the file in the debugger they will still be there.

If you subsequently edit the DriveBackup.cmd file outside of the debugger, and add or delete lines, then when you reopen that file in the debugger the breakpoints will appear to have shifted to a different line. In reality they are on the same line number as when you set them, but the debugger has no way of knowing you changed the file.

Could this be your situation?
 
MGibs said:
The status line in your screen shot for the find issue shows your cursor on line 536 and the "wrap around" checkbox in the dialog is not selected. Are there any breakpoints beyond line 536? If not, then the find command will stop searching at the end of the file and not "wrap around" to continue the search from the beginning of the file.
Click to expand...
Yes line 353, 420,
MGibs said:
Here's one way that can happen.

If you click in the margin to set a breakpoint on say line 3 in your DriveBackup.cmd file. Then save the file. Then close the file. The Debugger will save your breakpoints in a file named DriveBackup.cmd.bp so that when you reopen the file in the debugger they will still be there.

If you subsequently edit the DriveBackup.cmd file outside of the debugger, and add or delete lines, then when you reopen that file in the debugger the breakpoints will appear to have shifted to a different line. In reality they are on the same line number as when you set them, but the debugger has no way of knowing you changed the file.

Could this be your situation?
Click to expand...
Why would I save what is in the debugger? You told me I shouldn't change it and I already said it's read only even to change a variable I have to reset that every time a subscript reloads. So that doesn't make nay sense to me. There be no reason to save a script for a variable change. And the breakpoints are always on lines with nothing on them which would mean I'd be adding or deleting lines. I don't think I've done that at all.

Screenshot_20260611_115120_RVNC Viewer.webp


I verified the hard-coded lines (353, 420, 450, 460) and I will concede that it does appear that wouldn't be in a position that would allow "find" to work. I also moved the debugger display because I had to finda line to show you they are in there and that it wasn't being marked as a breakpoint. I suspect the very thing that was ignoring them in the script was probably the same problem with the find. I'll also mention that these breakpoints were supposed to be ignored by batch but because the CMDebug is not shutting down as a task that maybe what's causing all the errors in the console log when run outside of the debugger. I may have inadvertantly moved the current line setting up the screen capture. The other problem with your arguement was that I changed "down" to "up" and "Find" still couldn't locate them. I didn't just fall off a turnip truck. However, I'm not infoulible. Today it worked.
 
CityguyUSA said:
Are these ignored by normal execution? I can't even get the breakpoint on it's own line to be ignored. It doesn't break but it also reports every single one as an error.
Click to expand...

The BREAKPOINT command-line command does not exist in CMD or TCC-RT. If you're running the stand-alone CMDebug (which is a subset of the one in TCC or Take Command, and only includes TCC-RT, not the full TCC version) the parser will not recognize the command name.
 
The BREAKPOINT command works with the CMDebug Version 35 that I have when using test.btm

1781478809030.webp


Joe
 
Joe Caverly said:
Yep.

View attachment 5902

Ref: Comparing TCC, TCC/LE, and CMD

Joe
Click to expand...
So they're not ignored unless you have the whole TCC package installed and that's because it overrides CMD which may be an experience in commands that don't quite work the same from on to the other as I'm learning in another thread.

I'm just trying to get my script back from failng. I didn't really want to invest more into Windows as I got one server that is my last device running Windows. When I spilled iced tea on my laptop that I had spent almost $2K on I realized that I could run Android with an external monitor. I hear they are supposedly working on larger device support with Android. Plus there are other versions of Linux that supposedly have just as good an interface as Window's. That's not been my experience on Linux Distro's. I often have installs fail on Linux and then you end up tracking down libraries that don't exist anymore...it's the same problem that Android apps have. Developers get tired of maintaining them and abandon them - abandonware as I call it. And Window's isn't free from the problem either. Long-term legacy applications like Everything, Clipmate, etc are no longer supported. They run till they stop and you hope something comes along to fill the gap but I don't see anything on the horizon. Everything already has holes in the process that have never been addressed problems that he didn't account for in his results because of the method he uses to get around the problem of Window's and how it has to build a database and constantly refresh it which uses incredible amounts of CPU. It's the best of the what's available but you're putting your trust in it when you know it's flawed is hard. You never know if it's going to be supported or abandoned and now jpSoft and others are building it into their software and the guy that created it is missing. Hasn't responded to forum requests in years. Then he pops-up for a moment to say he's going to make a run at it again and disappears before his post has been read.

This is actually a serious problem that needs dealt with. Average users could care less but those of us that depend on products working get very frustrated with this. One of the first programs I bought was a file sync app back in the 1990's it had an incedible UI and then when computers went from 32 to 64bit they just abandoned it. So there went my investment. One of those purchases that was supposed to be a lifetime barely made a couple years and it was fairly expensive from what I remember like $70.

I guess intead of trying to repair this series of CMD scripts and Powershell scripts I should have fed it to Chat GPT to fix. lol I'm still not sure exactly what happened but there sure do seem to be several issues that I cannot explain. I've had serious issuses with Powershell and it's supposed ability to create filelists. It get's hung up in Window's security of all things. Wouldn't you think they'd have considered that when they wrote it? I don't even like Powershell it's wordy and convuluted and they seem to think it's a miracle betting the whole farm on it kind of like Window's 11 that real breakthrough for the Advertisement Desktop. I'd have prefered to stay with CMD but there are problems with file results in CMD too and I don't see them fixing it and then there are the quirky things like the Dir profiles that most of us don't know about.

There's no product that works consistantly.
 
Screenshot_20260621_184608_RVNC Viewer.webp


Anyone want to guess which breakpoint worked? It's the one on the closing parenthesis contrary to what I've been told.
 
CityguyUSA said:
View attachment 5951

Anyone want to guess which breakpoint worked? It's the one on the closing parenthesis contrary to what I've been told.
Click to expand...

An IF is one line, and one statement.

The execution pointer will pause at the end of the IF (line 78), which makes sense as you wouldn't be able to single-step to the next line in the batch file (79) if execution paused at line 76.
 
You must log in or register to reply here.
Back
Top