GUI Edit box not processing CRLF from Run StdoutRead

[mcBeth]

Version: (3.3.8.1) AU3Check (1.54.22.0) AutoIt3Wrapper v.2.0.1.24

Hello,

Why is text coming from a StdoutRead stream not correctly formatted in an Editbox?

Thx in adv

Im building a GUI to simultaneously Run multiple instances of a putty plink command.

The outputstream should be captured in separated Editboxes.

Output of finished sessions will be copied to a "merge" Editbox.

To get started I used koda building a simple GUI framework and added the provided example: Demonstrates StdoutRead() [stdoutRead.au3] and changed the command to be run plink....

By running this concept a msgbox is shown with descend formatting.

Then I added GUICtrlSetData() to capture the content in an Editbox

Running the mod. the CR & LF are ommitted in the Editbox

If I selectAll & copy/paste the text into an editor all CR & LF are still there.

This is the testingScript

expandcollapse popup

#include <Constants.au3>
#include <ButtonConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <GuiEdit.au3>

Opt("GUIOnEventMode", 1)

$Form1 = GUICreate("Form1", 479, 237, 192, 114)
GUISetOnEvent($GUI_EVENT_CLOSE, "Form1Close")

$edtStream1 = GUICtrlCreateEdit("", 0, 0, 377, 105)
GUICtrlSetData(-1, "edtStream")
GUICtrlSetFont(-1, 8, 400, 0, "Courier New")

$edtStream2 = _GUICtrlEdit_Create( $Form1, "", 0, 120, 377, 105)
_GUICtrlEdit_SetText( $edtStream2, "edtMerge")

$btnStart = GUICtrlCreateButton("btnStart", 392, 32, 75, 25)
GUICtrlSetOnEvent(-1, "btnStartClick")

GUISetState(@SW_SHOW)

While 1
Sleep(100)
WEnd

Func btnStartClick()
runCommand()
EndFunc

Func Form1Close()
Exit
EndFunc

Func runCommand ()
Local $foo = Run(@ComSpec & " /c plink -ssh sshSession2Celerra -m " & @ScriptDir & "\cmds_ls_tmp.txt", @ScriptDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)
Local $line
While 1
$line = StdoutRead($foo)
If @error Then ExitLoop
MsgBox(0, "STDOUT read:", $line)
GUICtrlSetData( $edtStream1, $line, 1 )
_GUICtrlEdit_AppendText( $edtStream2, $line )
WEnd

While 1
$line = StderrRead($foo)
If @error Then ExitLoop
; MsgBox(0, "STDERR read:", $line)
GUICtrlSetData( $edtStream1, $line, 1 )
WEnd

MsgBox(0, "Debug", "Exiting...")
EndFunc

[mcBeth]

Edit: I already tried stringsplit. It does not recon the @CRLF.

_ArrayDisplay() showed that the entire line is in [1]

and using Chr() instead of the macro doesn't work either

[javip]

mcbeth. it might have to do with the font and size.

i use this when using stdoutread to output to an editbox.

GUICtrlSetFont(-1, 10, 400, 0, "Lucida Console")

the spacing of certain fonts i noticed do not output stdoutread to edit box because the editbox supports a higher set of fonts and such like notepad., a 'mono' spaced font like Lucida Console should

output without any weirdness, like a regular cmd console box. the font sizing is pt 10. 8 is nice, but i like 10.

Edited September 19, 2012 by pixeldotz

[mcBeth]

Thank's for your reply pixeldotz

I've tried several font settings, even an OEMCONVERT but alas, none of them worked out right.

I wonder if this is a bug.

Even StringSplit() doesn't recognize the @CRLF.

otherwise _ArrayDisplay() would have displayed every line in a separate array cel

Putting a different delimiter into StringSplit(), _ArrayDisplay() does show multiple cel's

Local $arr = StringSplit( $line, "a7", 1 )
_ArrayDisplay( $arr )

I'm still puzzled

[BrewManNH]

I used the DIR command in place of Plink and it worked for me with your script as is. It might be an issue with Plink and not with AutoIt. You can always append a @CRLF to the end or beginning of the $line variable before putting it into the Edit box.

[mcBeth]

Thank's for your reply BrewManNH

Indeed running a native command will format correctly (I tried a few). And yes, one could blame it to plink.exe

In that case, one could blame it to any NONE native WindowsCommandShell command.

e.g. Build a console app, run it, and check the result.

I just wanted to see it for myself did it with this autoIT code:

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Change2CUI=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

# ConsoleReadWrite.exe
#include <String.au3>

Local $data
While True
$data &= ConsoleRead()
If @error Then ExitLoop
Sleep(25)
WEnd

Local $upper = _StringReverse( $data )
ConsoleWrite( $upper & @CRLF )

I changed my testing script line saying:

Local $foo = Run(@ComSpec & " /c plink -batch -ssh sshSession2Celerra -m " & @ScriptDir & "\cmds_ls_tmp.txt", @ScriptDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)

in to:

Local $foo = Run(@ComSpec & " /c dir | "& @ScriptDir & "\ConsoleReadWrite.exe " , @ScriptDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)

And again, the @CRLF's are omitted in the Editbox

So, okay: NONE native WindowsCommandShell commands are not handled well by GUICtrlSetData() and StringSplit() except for the MsgBox()

The more I think of it the more the suspect arises MsgBox() uses a different autoIT_class responsible for the IO handling than GUICtrlSetData() and StringSplit(). MsgBox() always displayed the IO stream by StdoutRead() nicely formatted.

I hope somebody has an eureka

Thanks in advance

[mcBeth]

Whoops, I ran out of the 5 credits [You can make 0 posts until 20 September 2012 - 12:24 PM.]

[BrewManNH]

I tried your test script and it wasn't working right with the edit control. I then tried everything I could think of to see why it wouldn't work, because I use this exact same technique in a script I have used for a couple of years now with an edit control and it works perfectly.

One of the tests I did was to take out the StringReverse part of the test script and then recompiled it, and it worked for me without that. So, I don't think it is the Edit control, or the way AutoIt reads from the StdOut streams, I think that issue was with the StringReverse function. I still think it's an issue with plink and not with AutoIt, because no matter what program I test (that outputs to the console) it works for me.

[guinness]

Whoops, I ran out of the 5 credits [You can make 0 posts until 20 September 2012 - 12:24 PM.]

You will have to wait as this is a measure in place to stop spamming of new accounts. Please don't create a new account to bypass this. See Forum Rules as to why I said that.

[mcBeth]

OT:

You will have to wait as this is a measure in place to stop spamming of new accounts. Please don't create a new account to bypass this. See Forum Rules as to why I said that.

1st of all: I respect the rules. it's the 1st thing I read before I commit myself to them. One could claim just anything

Though it wouldn't harm welcoming if a fresh member with your note and telling what to expect next. e.g. restrictions you mentioned and how long these last.

OT-END

Having said that, I proudly announce the solution to this topic.

I discovered that plink.exe marks it's EOL by a single LF control char.

Apparently MsgBox() takes a LF or CR or CRLF for granted

as for GUICtrlCreateEdit() requires specifically CRLF

So all that is needed is a function that, "Takes a string and prefixes all linefeed characters ( Chr(10) ) with a carriage return character ( Chr(13) )"

Cool! you guy's knew that all along cos that Func exists: StringAddCR()

One thing left to say:

how come Func _StringReverse() didn't act right?

Well it reversed the CRLF control char instead of leaving them alone. and therefor a LF was put before CR

Well, that's about it.

Bottom line: I now know the topic should have read: GUI Edit box not processing LF

I humble request the manual writers to add a note to the FAQ and Func: GUICtrlCreateEdit() and StdoutRead() pointing out this feature and link StringAddCR() to the Related.

Thx 2 @

Edited September 21, 2012 by mcBeth

[guinness]

1st of all: I respect the rules. it's the 1st thing I read before I commit myself to them. One could claim just anything

Though it wouldn't harm welcoming if a fresh member with your note and telling what to expect next. e.g. restrictions you mentioned and how long these last.

I don't know when the restriction ends, else I would have told you. It wasn't meant to be an aggressive message as you might have taken it, just so many new people create an account to bypass the restriction and this causes unnecessary hassle for the Mods. Anyway, glad you took note of the Forum Rules. You will go far here!