Can a compiled macro write to STDOUT?

[JonHodgson]

Is there anyway for a macro compiled to an exe write to STDOUT?

I want to output status messages as the script runs.

I know I can write to a file, but that doesn't help me. My .exe will be run by a scheduling application which read the messages from the console.

Maybe with VB?

Along the same lines, is there a way for me to specify the exit code of the .exe, so i can also use that as a mechanism to determine if it completed or i broke it in the middle etc.

[support]

Unfortunately not, because Macro Scheduler macros are not console applications.

For the status code I'd suggest setting an environment variable with SetEnvVar. This would then be available to the calling process.

[JonHodgson]

The SetEnvVar idea seemed decent. I tried this but it's not working the way i expected.

I created a simple compiled macro 'console.exe':
SetEnvVar>foo,Passed
wkd>g
and then i created a wrapper batch file 'consolebat.bat':
@echo off
console.exe
echo %foo%
pause
Using SysInternal's ProcessExplorer
http://www.sysinternals.com/ntw2k/freew ... cexp.shtml
i can see the running environment of the call tree.

like:
CMD.EXE
+---console.exe

and look at the running environments of each. console.exe does show foo=Passed, but CMD.EXE does not show foo at all.

I also tried pre-setting foo=bar before i ran the batch file, and in that case console.exe still shows foo=Passed but CMD.EXE has foo=bar

Any idea on how to set the environment of the calling process?

[support]

Unfortunately it seems CMD spawns a new process. But it does work the other way around:

SetEnvVar>foo,bar
Run>cmd.exe
WaitWindowChanged>5
Send>echo %foo%
Press Enter

Note the value of foo - "bar" - is output to the screen.

But this might not help you!

I've figured out a sneaky way to write to standard out. This will probably only work in XP and will only work if compiled to an exe and that exe is run FROM the command line. Compile the following script to an exe and then run it from a CMD console window:

//MUST BE LAUNCHED FROM CONSOLE

//Get Process of console window that launched us
//If neccessary change the window title to suit your setup:
GetWindowProcess>C:\WINDOWS\system32\cmd.exe,pid,pname

//Attach to console
LibFunc>kernel32,AttachConsole,aok,pid
LibFunc>kernel32,GetStdHandle,consolehwnd,-11

//Give the console a new title - for fun
LibFunc>kernel32,SetConsoleTitleA,tr,My Macro's Console Window

//Write to it's STDOUT
Let>Message=Hello World%CRLF%
Length>Message,LenM
LibFunc>kernel32,WriteConsoleA,wcres,consolehwnd,Message,LenM,0,0

//Wait 5 seconds
Wait>5

//Write to STDOUT again
Let>Message=Bye World%CRLF%
Length>Message,LenM
LibFunc>kernel32,WriteConsoleA,wcres,consolehwnd,Message,LenM,0,0

//Remember to close console at end of script
LibFunc>kernel32,CloseHandle,cr,consolehwnd


To be honest, I think what I would do for outputting progress info is just have the macro create a simple dialog with a large memo on it, then just open it non-modal and whenever you want to output data reset the memo with new data. This would work in any environment.

[JonHodgson]

Thanks for looking into this. I'm on Win2K Pro but tried your script anyway, and sure enough it didn't work. Most of the machines I would deploy this to will be Win2K, so this doesn't help me, but definately good info for the future.

The memo idea won't help me since the calling app needs to automatically scrape the status messages from the STDOUT.

As a near-term workaround i'm simply going to have the script output all messagas to a textfile, and then have the wrapper batch file type the file out to STDOUT. It's not optimal, as i'll only get my messages at the very end of execution, but it should work.

This might be a nice feature for you to think about for the future.

Thanks for all your help.

[support]

This might be a nice feature for you to think about for the future.

Unfortunately Windows is a bit of a cludge when it comes to the console. Applications can either be console applications or GUI applications. They can't be both. So this is going to be quite a challenge.

It was only with Windows XP that they finally provided that AttachConsole function which gave me that work around idea.

The obvious answer is for us to look at the possibility of a compiler that can create either a console app or a GUI app. We're talking very complicated stuff here so I can't see this happening any time soon. Scripts would only be able to do certain things depending on whether they were console or GUI apps. We also have to weigh up the cost and time of doing such work against the benefits and consider how many people actually need something like this. My gut feeling is that it isn't worth the effort for something this complicated and only of use to the minority.

Time might be better spent coming up with a workaround. Here's an obvious one which we could create in an hour or two:

A console application which starts the Macro Scheduler exe and creates a DDE server. The Macro Scheduler exe sends text back to the calling console app via the DDEPoke command. The console app then writes that data to the console. Problem solved. Instead of starting the Macro Scheduler exe you would start the wrapper console app with the Macro Scheduler exe as a command line parameter. The communication method doesn't necessarily have to be DDE but since a DDEPoke command exists in Macro Scheduler it seems an obvious choice.

If you're interested we could create this for you.

[Marcus Tettmar]

Just to let you know that version 11 will let you compile macros to "Console Apps" which can then write to StdOut with the functions SOWrite and SOWriteLn. This is currently in production and an announcement will be made when it is ready for beta testing.