Welcome!

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

SignUp Now!

Parameter-handling discrepancy in debugger when stepping

old coot

old coot

May
62
1
In the following example:
  • The main routine gets the first batch parameter and strips it off. It then calls SUBR, which does the bulk of the work.
  • SUBR calls SUBR2, which gets the next batch parameter and strips it off.
  • SUBR then processes the rest of the parameters.
Code: 
[D:\TMP] type foo.btm
@ echo off
  echo Input parm string is %*
  echo parm1 starts out %1
  shift
  echo after shift, parm1 is %1
  gosub subr
  echo at end, parm1 is %1
  quit

:SUBR
  gosub SUBR2
  echo in SUBR, processing remainder of parms, which are %$; parm1 is %1
  do while (%1) ne ()
    echo In SUBR loop, parm1 is %1
    shift
  enddo
  return

:SUBR2
  echo In SUBR2, parm1 is %1; shifting out
  shift
  return
The output is as I expected (pay attention to the parameters that SUBR sees):
Code: 
[D:\TMP] foo /mainoption /secondoption set1 set2 set3
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
In SUBR2, parm1 is /secondoption; shifting out
in SUBR, processing remainder of parms, which are set1 set2 set3; parm1 is set1
In SUBR loop, parm1 is set1
In SUBR loop, parm1 is set2
In SUBR loop, parm1 is set3
at end, parm1 is
If I simply run to end in the debugger, it produces identical output. However, if I step through the entire code, SUBR does not see any batch parameters:
Code: 
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
In SUBR2, parm1 is /secondoption; shifting out
in SUBR, processing remainder of parms, which are ; parm1 is
at end, parm1 is
I thought this had something to do with GOSUBs more than one level deep. But if I comment out the call to SUBR2 and step through the code again, it produces equally disturbing results: the first two of the remaining batch parameters are seen, but the last two are skipped.
Code: 
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
in SUBR, processing remainder of parms, which are /secondoption set1 set2 set3; parm1 is /secondoption
In SUBR loop, parm1 is /secondoption
In SUBR loop, parm1 is set1
at end, parm1 is
Am I seriously abusing batch parameter references, or is this a bug?
 
Hmmm! It's OK here using any of the stepping buttons. Using "step into" 21 times I get this, which looks correct.

Code: 
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
In SUBR2, parm1 is /secondoption; shifting out
in SUBR, processing remainder of parms, which are set1 set2 set3; parm1 is set1
In SUBR loop, parm1 is set1
In SUBR loop, parm1 is set2
In SUBR loop, parm1 is set3
at end, parm1 is
 
That's what I'm doing: "step into". So something must be different about my setup. What could that possibly be?

Take Command v28.01.14 x64
Windows 10 Pro
 
I'm starting it like this.

Code: 
bdebugger coot.btm /mainoption /secondoption set1 set2 set3

Maybe build 18 will fare better.
 
I also tried "start debugging" then entering the parameters in the watch dialog, as
Code: 
1=/mainoption
2=/secondoption
...

That was OK also.[/code]
 
P.S., But doing it that way, the parameters are not remembered for the next run. :-(
 
I was entering the parms in the ribbon in the debugger.

Going to 18 fixed it. Thanks, Vince!
 
Are the parameters remembered if you enter them in the ribbon?
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate