- Dec
- 238
- 2
In another thread, I wrote:
> It was extremely handy in the 4NT days to be able to insert a "setdos
> /y1" command into a script being tested, launch the script at the
> command line, and then go into debugging mode immediately after the
> "setdos" statement was encountered. This is no longer possible with
> BDEBUGGER (at least, it wasn't at the time we exchanged forum messages
> about it before). This to me is also a major loss of important and
> useful functionality. It would be a great improvement if an "open the
> script in the debugger and pause here" feature were available again.
Your (Rex's) reply:
I'm still completely inexperienced with TCC (versus 4NT, which I used since the Neolithic): I read the documentation for BREAKPOINT and found that the debugger has to be running for the command to work. So I ran it, then put a BREAKPOINT statement into a .btm file, then ran the .btm file from the TCC command line.
I assumed -- incorrectly, I guess -- that this would cause the script to then appear in the BDEBUGGER window, paused at the BREAKPOINT statement. It didn't happen.
What is the correct procedure for getting this result (if it's possible)?
I found that running BDEBUGGER did not return control immediately to the user (at the command line); it was like using "start /wait". I tried "start bdebugger" but that opened another command shell (before launching the debugger). Is there a way to run the debugger and then immediately get control back at the same command prompt where the command was launched -- without opening a second TCC console window? That is, before BDEBUGGER exits?
> It was extremely handy in the 4NT days to be able to insert a "setdos
> /y1" command into a script being tested, launch the script at the
> command line, and then go into debugging mode immediately after the
> "setdos" statement was encountered. This is no longer possible with
> BDEBUGGER (at least, it wasn't at the time we exchanged forum messages
> about it before). This to me is also a major loss of important and
> useful functionality. It would be a great improvement if an "open the
> script in the debugger and pause here" feature were available again.
Your (Rex's) reply:
I'm still completely inexperienced with TCC (versus 4NT, which I used since the Neolithic): I read the documentation for BREAKPOINT and found that the debugger has to be running for the command to work. So I ran it, then put a BREAKPOINT statement into a .btm file, then ran the .btm file from the TCC command line.
I assumed -- incorrectly, I guess -- that this would cause the script to then appear in the BDEBUGGER window, paused at the BREAKPOINT statement. It didn't happen.
What is the correct procedure for getting this result (if it's possible)?
I found that running BDEBUGGER did not return control immediately to the user (at the command line); it was like using "start /wait". I tried "start bdebugger" but that opened another command shell (before launching the debugger). Is there a way to run the debugger and then immediately get control back at the same command prompt where the command was launched -- without opening a second TCC console window? That is, before BDEBUGGER exits?
