Compile stops at Command Results

[Arne Hartelius]

Need some help with a small but rather irritating problem. I installed Borland C++ Free Command Line Tools and it works fine with one exception. When I compile a program with no errors the Command Results produces this text:

C:\SourceCode\HelloWorld.cpp:

Tool completed successfully

and then stops there.

In contrast when I compile a Java-program with no errors the Command Results produces this text:

Tool completed successfully

and then jumps back to the source code which I think is the desired behavior.

In both the Java and C++ case it works fine to jump to the line of error by double clicking on the error message when the compile is not succesful.

It seems to me that the echoing of the source code filename is the thing that stops TextPad from returning to the source code. Maybe TextPad will return only if Command Results produces an empty page, apart from the "Tool completed successfully" message which is produced by TextPad itself. But this is only guess work on my part.

Anyone who can help me with this ?

[Mark Schnitzius]

I suspect your theory is right about it depending on whether or not it receives output. Maybe you can change the compile tool definition so that it sends output to a junk.txt or something? Like, add a " > junk.txt" to the parameters list of your compile command.

Depending on your environment, this should only redirect standard out to the file; errors should still be printed to the output window since they're sent to stderr... I hope.


--Mark

[Arne Hartelius]

First of all, thanks a lot for your replay. It's nice to get some response.

I'm not sure exactly WHERE to add the "> junk.txt" parameter. As I remember it the more-than-sign ">" had something to do with redirecting/appending output to a file in the olden, golden DOS days so your idea seems cleaver. I did try to put it at the beginning as well as the end of the parameter list but with no luck.

I suspect the parameter list only wants arguments directly aimed at the compiler bcc32.exe.

My enviroment is Win2000.

Arne

[Rich]

I have follow that 2000 "behaves" better when command-line tools are setup as "DOS Command" and not "program." This causes them to use the cmd.exe tools, which fixed problems I was having with improper output capturing.

[Arne Hartelius]

Hello Rich!

Thanks for your reply.

I did try your tip but with no luck I'm afraid. Still, all hints will probably be useful in the end because the solution is often a combination of all or most of these pointers.

Arne