cmd shell output (console)

[vmguy]

Valik, you must be right. -Bye

Edited November 12, 2006 by vmguy

[Valik]

You posted in the thread that contains the "answer". You have to use my stub program to launch the AutoIt script so it can bridge the gap between the console and AutoIt. However, I doubt that's necessary. Have you actually tested this script from within your build environment? It's obviously capturing the std streams or re-directing them if it's capturing the data so it will provide AutoIt with a valid handle to write to, even if a real console does not.

[Valik]

The "answer" does not address the "question".

No, the asker doesn't know what they are talking about and is trying to tell somebody who does they are wrong.

- I do not need a bridge that launches a new environment

No, you need a bridge that sits between two environments and allows them to talk to each other, which is what stub.exe does.

- This autoit script must operate as a command

I don't see why this needs stated.

- The autoit script itself already launches another command (tasklist), and as you

state, it is handling the redirected output from tasklist.

Again, this is irrelevant.

- I wish to produce my own diagnostic messages ... these are not being displayed

No shit. And it will never be displayed until you run your script via stub.exe. WINDOWS APPLICATIONS CAN NOT WRITE TO A CONSOLE window. PERIOD.

- It the output of that command that I am trying to represent as a Windows command

What?

- As you have already stated elsewhere, we don't need two commands to solve

these problems.

I stated that? No, I don't think so, at least not relating to this subject. You simply will not be able to do what you want without my stub.exe, whether you want to believe that or not.

I can accept the answer nobody knows how to do this.

So you are calling me a nobody? Because I know how to do this and anybody who's read this thread should know how because I told you.

Can you address the question of why the second sample program I posted

is causing a crash? It produces one line of output, then crashes.

Did you try it?

No, I didn't try it and I don't care to. You've taken a long way to do what ConsoleWrite() does for you. Congratulations.

Edit: Speaking of trying things, did you by chance bother to try inserting the script into the environment even though it's not writing to a console window? As I told you already, if the build environment is capturing the output, the odds are very high that it will "just work" even though it may not work when run from a console.

Edited November 10, 2006 by Valik

[DaveF]

I do not want to complicate the execution environment by using other invocation mechanisms.

The output from this command, and all the other build commands, is placed in a log file.

The STDOUT disconnect performed by the Windows shell on the STDOUT of Windows applications only occurs if the output "consumer" is the console, if the output is being redirected (like to a log file or the input pipe of another app) then the output pipe connection will be preserved. Try:

ConsoleWrite("This is a test.")

Run from a command line like:

console-test.exe > console-test.txt

[Valik]

vmguy, my hammer is made for this nail. I suggest you put down your crack pipe for a few minutes and try what I say instead of telling me how something works that you don't understand.

For the final time, try your damn script. If it doesn't "just work", then you will have to use stub.exe or you're on your own. There is no "compile to console" feature.