Make ConsoleWrite write to the console

[lod3n]

Oh, but you can. In fact, it's insanely simple. First, write and compile your stdouttest.au3:

consolewrite("Hello from AutoIt!")oÝ÷ Ø×±¶f¤y©b¶Ù^m«ø¥zV®È^­ú+Ê«±Êâ¦Ûa¢è!)¶¬r^r¬¥ç?
Ë]¢ëmzË^ÅçâßÕßø¥«¬{÷(uê+ü¨»§¶Ú,yëaz­¦ë[yú+{*.r©W£ºË]¢+eG­+¡×¢k)yÏÂß¹óOv>º ­©W¬Óݺڷ}=Ù·­kOvjëhÝÞÅíø²×hºÛ^²Ö®Ýø§wõwã~)jëýÊyhZ·l§áz·zYpéò¢êî*.­Ê&¦)^tL^¢°.¶­Ýì^o,ÊÝ¢æåyÉbrH§Ú«·~)^Ê­ë¬xwhÃl
·µãë¡Ç¬³brÞr'7¬ëh"ÝÞÅæ§u©òr©Wëh"Úk¢
Ú«ih§v,B¦bq«b¢Ûz÷§ü¨¹Ú'ßÛn±ëaxe~éܶ*'²Ê"µ§-÷¥ÉجrçyËl~º&¶L3M·jëì°,(ºWr¢ìÛh¸­zÚ-ç(Ê%z'í+"²}ýµ ÎIªi®(!´Â§Ê«º{(ëax0Ømà¨f§tízºkz׫rg^Åè­v¬mz0rì¢W¦bq«b¢{®°whÂÆ©¦XjبÇë¢g!É
Ú¿&§v¬uç_y«n­ë0'!Ê'½éâz{eËø­º¹è}ôå~ò¢àn¶»§)àÜ"¶&uì^É÷öק¢è!jÆ¥*.ßÚÞv§+%zÛbay$Ã9D쵬+ÞI0ÎQ;-Ygyçl²¶§Ú¢Ø^Âä¡ö¶æ¥+h¸­x"¶­¶ayÊ'²^jwm«wöÌ!z· ÐÿV«¨¶«¨µÊ&zȧZ­¶¬Â+ëºÇv¬yÈhm§$j|­)àr¢§¶H4=ý±$à Ûaj×hzÉèµÊ'µ¨§ªê-ªê-Â)yû¥(¬z÷«ÊØbxky©eÊ+-«^jÌ~ÞÁêÞ²§rX§yÛa{'(ºW`zШÊ%yjâµé²Æ zÆÚrGë¢g!WZºÚ"µì^²»§¶¬Á¬ºÚ"µÍÚ[ÛYH    ÐÛÛÝ[Ë]LÉÝÂÌÍÙÛÈH[ÛÛTÜXÈ   [È ÌÎNÈØÈÝÝ]Ý^H[Õ ][ÝÉ][ÝÉÌÎNËØÜÕ×ÒQK ÌÍÔÕÕUÐÒS
BÌÍÛÝ]]H    ][ÝÉ][ÝÂÚ[HB   ÌÍÛÝ]]  [ÏHÝÝ]XY
    ÌÍÙÛÊBYÜ[^]ÛÜÙ[ÙØÞ
    ][ÝÑÛÝÈÛHÚ[ULÈ^I][ÝË  ÌÍÛÝ]]

[Valik]

If you read it wasn't possible, you didn't fully read what you read. See here.

[lod3n]

Actually, I did see that, but I decided to just address and take advantage of what's actually happening instead of muck about in the binaries of my programs. My way seems a little safer and easier, and it took me about 2 minutes to develop a working model.

However, your way is much more interesting! Kudos on that work!

Edit: Oops! I see now that it wasn't you that wrote the one that messes with the binary, you wrote Stub.exe, which is pretty awesome. Still, I like my method a lot because I can do it in pure AutoIt, and with ConsoleRead on the child process, I can even have two way communication, again in pure AutoIt.

Edited August 25, 2006 by lod3n

[theguy0000]

is there some way to use @pause without it saying "press any key to continue"?

[vim]

If you read it wasn't possible, you didn't fully read what you read. See here.

That's some very interesting reading. I was suprised that someone went to all that trouble to hack AutoIt or knew where to do the hack. I could foresee all kinds of problems if his hack code was used extenstively and the support or lack thereof.

That "stub coding" of your was very impressive.

ViM

Edited August 26, 2006 by vim

[Valik]

You're talking about two different things.

Inter-process communication using std handles, ironically enough, was suggested by me to DaveF. That is a different concept than communicating with a console window. It also does not require reflecting the stream data through the command interpreter at all since both processes have read or write handles to the communication stream.

To communicate with a console, you're not going to be "pure AutoIt" unless you hack the binary. You're just using a feature of the command interpreter and find.exe to direct the stdout stream of a GUI-subsystem application to the console. The stub I wrote reflects all 3 std streams so that the GUI-subsystem application looks and behaves just like a console application. Your solution is very limited in what it can do. My solution is only limited if you try to access the framebuffer of the console directly, which isn't supported.

I would argue that stub.exe is a better choice because:

• It eliminates a lot of overhead involved with piping the data into find.exe.
• It eliminates the overhead of find.exe searching the data for an empty string.
• It redirects all streams, not just the output stream.

[theguy0000]

based on your method (well actually it is exactly your method but automated)

Func _consolewrite($text)
    $file1 = FileOpen ("C:\console.au3", 2)
    FileWrite ($file1, 'consolewrite("'&$text&'")')
    FileClose ($file1)
    $file2 = FileOpen ("C:\console.bat", 2)
    FileWrite ($file2, '@ %comspec% /C "C:\Program Files\AutoIt3\autoit3.exe" C:\console.au3 | find /V ""'&@CRLF)
    FileWrite ($file2, "@ pause > nul")
    FileClose ($file2)
    Run ("C:\console.bat")
EndFunc

Edited November 7, 2006 by theguy0000

[Valik]

Your solution is very limited in what it can do. My solution is only limited if you try to access the framebuffer of the console directly, which isn't supported.

I stand corrected. I've just done some experimenting and with a single line of code (that is not requried in a true console application), all the Console functions defined by the Windows API become available for a GUI application to use on Stub.exe's console window.

Simply using DllCall() to call "AttachConsoel(-1)" will associated the AutoIt script with Stub.exe's console window. Then all calls to WriteOutput or any other console related Windows API function will work correctly. I've just successfully written red text to a console window reflected by Stub.exe from a non-compiled AutoIt script.

I also found a bug in Stub.exe. Maybe someday if I'm bored and remember, I'll fix Stub.exe, put together a couple examples and upload it all to it's own thread. The moral of the story is Stub.exe is more powerful than I ever imagined and is the perfect tool for reflecting std stream data from a console to/from a GUI-subsystem application.

Edit: Just a small hint. After calling AttachConsole(), the AutoIt script has to open the screen buffer by calling CreateFile() directly (via DllCall()). You need the actual handle returned by CreateFile() and not the pseudo-handle AutoIt returns.

Edited August 26, 2006 by Valik

[lod3n]

I've been playing around with stub.exe and it is indeed pretty heavy duty. I look forward to any forthcoming versions...

[bluesxman]

is there some way to use @pause without it saying "press any key to continue"?

Yeah, like this:

@pause > nul

~bxm

[archjonesy]

Is it possible to use stub.exe to allow autoit to interface with console applications? If so how?

I'd like to use autoit to interface with different console apps, but the only thing I can come up with is blind writing to the console and hope it doesn't take longer than the sleep I put in... there HAS to be a better way.

Thanks!

[M4M]

Yeah, like this:

@pause > nul

~bxm

when you do that, doesnt it create a file called "nul" with the text "press any key to continue" in it?

a simple fix for then would be to just add:

del nul

[Valik]

"NUL" is the Windows equivalent of /dev/null. It just discards whatever you pipe into it.

[orip]

Thanks, that's very helpful!!

I made the following generic batch file wrapper 'autoit_console.bat':

@echo off
rem workaround to make AutoIt executables "consoleable"
rem From http://www.autoitscript.com/forum/index.php?showtopic=31607
%COMSPEC% /c %* | find /V ""

I use it like this:

autoit_console.bat ...\my_compiled_autoit_script.exe [params]

[Jos]

You could also use the new option available in the aut2exe or AutoIt3Wrapper:

#AutoIt3Wrapper_Change2CUI=y

[JRSmile]

Just use this: CLICK HERE