Welcome!

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

SignUp Now!

Associating BTM files with IDE results in DOS box

Aug
124
0
Hi,

I've associated .btm files with Take Command's IDE (.btm="F:\program files\take command\ide.exe" "%1") in order to get better syntax highlighting. Now, when I click a BTM batch script, I get the IDE plus an additional blank DOS box (as if ide.exe wouldn't be a GUI application). How can I fix this?
 
TCC is inherently a console program; there will always be a console window. It may be hidden -- if, for example, it's running in Take Command -- but there will be a console window. Where else would the batch file's output be displayed?

I suppose you could do something like this:

Code:
assoc .btm=btmfile
ftype btmfile="%@path[%_cmdspec]tcmd.exe" /c "%@path[%_cmdspec]ide.exe" %%1

Not tested!
 
Hi,

I've associated .btm files with Take Command's IDE (.btm="F:\program files\take command\ide.exe" "%1") in order to get better syntax highlighting. Now, when I click a BTM batch script, I get the IDE plus an additional blank DOS box (as if ide.exe wouldn't be a GUI application). How can I fix this?
DOS box? ... or TCC box? A BTM file must run in TCC and IDE creates a TCC to do that.
 
Conhost. I just want to open the file in IDE - not run
If not started from TCC, it aparently allocates a console (even if you don't run it). An "edit" mode (no console) would be nice but I don't think it has one. I'd vote for that feature.

I just noticed a small (unrelated) anomaly. If, in CMD, I "g:\tc15\ide.exe BTMfile" and then run the BTMfile from within IDE, then IDE starts/stops TCC (in the same console as CMD) to run the BTMfile (that's OK). But when I'm all done and close IDE, the cursor is no longer visible in the CMD console.
 
Hi,

I've associated .btm files with Take Command's IDE (.btm="F:\program files\take command\ide.exe" "%1") in order to get better syntax highlighting. Now, when I click a BTM batch script, I get the IDE plus an additional blank DOS box (as if ide.exe wouldn't be a GUI application). How can I fix this?


The IDE always opens a console window. There is no way to disable that.
 
The IDE always opens a console window. There is no way to disable that.

When I open IDE and then open a batch file, there is no - visible - console window. When I open IDE and directly pass it a Batch file name, it opens with a visible console window. And you say there is no way to disable that???
 
When I open IDE and then open a batch file, there is no - visible - console window. When I open IDE and directly pass it a Batch file name, it opens with a visible console window. And you say there is no way to disable that???


That's correct. If IDE is opened from an existing console window, it will use that console for its debug window. Otherwise, it creates a new console window at startup.
 
When IDE is used only to edit a file, which is possibly not even a .BTM file (ref: IDE also includes syntax colorization for Perl, Python, Ruby and Tcl), it would make sense to be able to invoke to IDE.EXE without a console window, possibly as a non-default option. For BDEBUGGER the current operation is the only one that makes sense.
 
When IDE is used only to edit a file, which is possibly not even a .BTM file (ref: IDE also includes syntax colorization for Perl, Python, Ruby and Tcl), it would make sense to be able to invoke to IDE.EXE without a console window, possibly as a non-default option. For BDEBUGGER the current operation is the only one that makes sense.


Cannot be done without a major rewrite (at least 2-3 months work). You can add it to the suggestion forum if you think it's more important than your other suggestions.
 
Since the current operation is NOT harmful, any more than a few hours of work to change it is not worth the effort. I prefer my other suggestions, thank you.
 
Cannot be done without a major rewrite (at least 2-3 months work). You can add it to the suggestion forum if you think it's more important than your other suggestions.
How about a start-up option for IDE that will cause the console to be hidden (perhaps even with it automatically showing if (later) it's needed)? That'd make using IDE as an editor a bit more tolerable.
 
How about a start-up option for IDE that will cause the console to be hidden (perhaps even with it automatically showing if (later) it's needed)? That'd make using IDE as an editor a bit more tolerable.
In fact, that seems like reasonable default behavior ... if IDE allocates a console, let it be hidden until used. It's pretty useless if it's not used by IDE!
 
How about a start-up option for IDE that will cause the console to be hidden (perhaps even with it automatically showing if (later) it's needed)? That'd make using IDE as an editor a bit more tolerable.


Sure, if you can convince Microsoft to change their APIs to allow me to create a console hidden. (That's never been supported in Windows.) The best that can be done is create it visible, then immediately hide it. People tend to find that more irritating than simply leaving it in the background.
 
Sure, if you can convince Microsoft to change their APIs to allow me to create a console hidden. (That's never been supported in Windows.) The best that can be done is create it visible, then immediately hide it. People tend to find that more irritating than simply leaving it in the background.
You could start a hidden TCC that would exit when IDE has attached to it's console. I've tested that (crudely) and it works.
 
I could, if I wanted to discard the existing architecture and rewrite IDE. (There's a lot more going on there than you realize.)

But I don't really want to, and I don't think there's any need for it.
I kinda like the idea of using IDE as an editor.
 
I'm surprised that console windows are Bad now. For many years it was the other way around -- the console window was Good, and anything that opened outside the console was Bad.
 
It's used for many things in the IDE, even when you're not debugging a file. The IDE (like TCMD) is constantly running things in TCC and TakeCmd.dll.
I don't fully understand. If I start IDE from explorer, I can edit/debug/run a batch file without ever starting an instance of TCC. TCC seems necessary only if the batch file demands it, for example because of piping.
 
I don't fully understand. If I start IDE from explorer, I can edit/debug/run a batch file without ever starting an instance of TCC. TCC seems necessary only if the batch file demands it, for example because of piping.


I can assure you that IDE has to run TCC in order to debug or run a batch file. (Whether or not you see a tcc.exe instance in the process explorer is irrelevant.) Exactly how the IDE does it is rather complex (and proprietary).
 
I can assure you that IDE has to run TCC in order to debug or run a batch file. (Whether or not you see a tcc.exe instance in the process explorer is irrelevant.) Exactly how the IDE does it is rather complex (and proprietary).
I don't know what you mean by "run TCC" but, after g:\tc15\tcc.exe has been deleted, g:\tc15\ide.exe (started from Explorer) manages to edit/run/debug a BTM file just fine!

Is there a polite way for another process to ask an existing TCC to exit? ... SendMessage maybe?
 
I don't know what you mean by "run TCC" but, after g:\tc15\tcc.exe has been deleted, g:\tc15\ide.exe (started from Explorer) manages to edit/run/debug a BTM file just fine!

Is there a polite way for another process to ask an existing TCC to exit? ... SendMessage maybe?


TCC.EXE doesn't have any code to speak of; it's just a thin wrapper around the real code. And TCC is included inside IDE, so unless you also delete IDE.EXE and then edit/run/debug a BTM file, you haven't proven anything.

You can't send a message to TCC; it's a console app and doesn't have a message queue. You have to send it to conhost. (Well, actually, TCC *does* have a hidden message queue, but it's only for communication with TCMD -- all the details are in the help file.)
 
TCC.EXE doesn't have any code to speak of; it's just a thin wrapper around the real code. And TCC is included inside IDE, so unless you also delete IDE.EXE and then edit/run/debug a BTM file, you haven't proven anything.

You can't send a message to TCC; it's a console app and doesn't have a message queue. You have to send it to conhost. (Well, actually, TCC *does* have a hidden message queue, but it's only for communication with TCMD -- all the details are in the help file.)
I figured that. My point was only that TCC.EXE was not run.

I've been aware of TCC hidden window for ages. Sending it "WM_ENDSESSION,1,1" seems to work. Is there anything untoward about that? I don't want conhost to exit in case anything else has attached to the console.
 
I've been aware of TCC hidden window for ages. Sending it "WM_ENDSESSION,1,1" seems to work. Is there anything untoward about that? I don't want conhost to exit in case anything else has attached to the console.


It'll only work in some versions of TCC (not before v9, not after v15, and not in TCC/LE). And it'll definitely break things if TCC is in a TCMD tab window, or if you have more than one TCC instance active.
 
It'll only work in some versions of TCC (not before v9, not after v15, and not in TCC/LE). And it'll definitely break things if TCC is in a TCMD tab window, or if you have more than one TCC instance active.
What will happen to other instances of TCC if I send "WM_ENDSESSION,1,1" to a particular "TCC:<pid>" window? I haven't seen any side effects (but I haven't looked very hard).

I'm working on a little (GUI, no window) app, JE.EXE, to start IDE.EXE with it's console hidden. It uses a hidden TCC and that's the one I want to exit after IDE has attahed to its console. Actually, I suppose I could avoid TCC altogether and run (hidden) "cmd /k title TCC Prompt & [path\]ide.exe ..." and just kill the CMD process but that wouldn't be a nice thing to do.
 
I'm surprised that console windows are Bad now. For many years it was the other way around -- the console window was Good, and anything that opened outside the console was Bad.
I think the primary issue is not text v. graphic window, but single window v. two windows. To edit a file you do not need a second window, visible or hidden. In fact, since IDE can only edit plain text files, without graphics or any need for WYSIWYG capability, strictly speaking the edit window could even be a text window. There are advantages to it being a graphical window, e.g., permitting display of information based on file content, but there is no need for a second user interface (a second window) when you use the primary one strictly for editing only.

Note that I the terminology I used is descriptive of the functionality of the windows used, not what method MS chooses to implement them or their misuse of English referring to them (think of a console TV set).
 
I don't think of the extra console window as a user interface (you can't give it input). Rather it's for output (a BTM must output to a console window). But I, like the OP, would rather not see it if I only want to edit the BTM fie. I understand that getting rid of the console (the one allocated when IDE is started from outside TCC) may not be feasible. Starting IDE.EXE with the console hidden isn't too hard. If only it had a toolbar button to hide/show the console it's attached to and/or if it automatically showed that console (in case it's hidden) whenever you run or debug ...
 

Similar threads

Back
Top