WAD Invoking BDEBUGGER changes window title to "TCC Prompt"

[Steve Fabian]

TCC 14.02.41 Windows XP [Version 5.1.2600]

Executing the command below in stand-alone TCC window changes window title to TCC Prompt:

bdebugger %@search[sethr] 1024

Note: sethr.btm is on the path, the command starts it in the debugger.

 

[rconn]

TCC 14.02.41 Windows XP [Version 5.1.2600]

Executing the command below in stand-alone TCC window changes window title to TCC Prompt:

bdebugger %@search[sethr] 1024

Not reproducible here, either in a TCMD tab window or a stand-alone TCC console window.

You are aware that BDEBUGGER will start a new TCC session? Do you have a TITLE command in your TCSTART? Or do you have "UpdateTitles=No" in your TCMD.INI?

 

[Steve Fabian]

You are aware that BDEBUGGER will start a new TCC session?

Yes, I am aware. What is not clear is what is run in the new session - the batch file being debugged or the debugger itself, though from the fact that variables created or modified (and not subject to SETLOCAL) in the batch file being debugged are not propagated to the command prompt after debugging is finished implies it is the debugged program.

Do you have a TITLE command in your TCSTART?

Yes. The "TCC prompt" title has no resemblance to what TITLE is supposed to build.

Or do you have "UpdateTitles=No" in your TCMD.INI?

Yes.

 

[rconn]

Yes, I am aware. What is not clear is what is run in the new session - the batch file being debugged or the debugger itself, though from the fact that variables created or modified (and not subject to SETLOCAL) in the batch file being debugged are not propagated to the command prompt after debugging is finished implies it is the debugged program.

The new session is the debugger itself, running as a GUI app. The debugger then opens a console window (or shares the existing console window, depending on how it was opened) to display the output from the batch file. There is no child TCC.EXE process involved; it's all being run inside IDE.EXE.

There is no way you can propagate variables from a child process (the debugger) back up to the parent process.

 

[Steve Fabian]

Your change of the thread status indicates that despite the explicit use of the TITLE command to provide a unique title to each TCC window, setting the directive UpdateTitles to No to ensure they are not changed, it is intentional that using and terminating the debugger change the title of the window from which invoked to "TCC Prompt", a title far from unique, and leave it changed when debugging is complete. I would like to know the reason for overriding the user's selection of window title. As it is I consider this a BUG: changing an identification (used e.g. by TASKLIST) contrary to user choice.

 

[vefatica]

When I issue "BDEBUGGER BTM_name" in a stand-alone TCC with UpdateTitles=No and TITLEPROMPT set the console's title does change, but only briefly. Must it change at all?

 

[rconn]

My point was that you're not running TCC, you're running a GUI app (ide.exe) that doesn't know (or care) what your console window title is. If you have"UpdateTitles=Yes", then the original title will be restored when ide.exe exits. Or, if you run the debugger in a separate console session, then the TCC title will never be altered. But if you want to run BDEBUGGER in your current stand-alone TCC console window and you have "UpdateTitles=No", then TCC isn't going to restore its title when the debugger exits. This is WAD, and the batch debugger has behaved this way since it was first created.

I think you're going to be happier with "start bdebugger".

 

[vefatica]

Unless I'm misunderstanding you, it doesn't work that way. As I said before,

When I issue "BDEBUGGER BTM_name" in a stand-alone TCC with UpdateTitles=No and TITLEPROMPT set the console's title does change, but only briefly.

By "briefly" I mean a split second . The caption quickly reverts to TITLEPROMPT. And it stay's that way when debugging is started. Momentary caption changes have always annoyed me.