Run/RunWait & StdoutRead issues

[Guest vzb]

Hi,

I'm trying to build some SW projects using a Perl script and redirect the output of the script to an Edit control using

Run ( "filename" [, "workingdir" [, flag[, standard_i/o_flag]]] )

The Perl script works all right in a DOS box and redirection in the Edit control basically works using the sample code I found somewhere:

If $Process Then
; Calling StdoutRead like this returns the characters waiting to be read
    $CharsWaiting = StdoutRead($Process, 0 , 1)
    If @error = -1 Then
        $Process = 0
    EndIf       
    If $CharsWaiting Then
        $CurrentRead = StdoutRead($Process)
        GUICtrlSetData($EditCtrl, $CurrentRead, 1)
    EndIf
EndIf

However, for some larger projects the ouput suddenly stops towards the end of the linking process, i.e. the last ~30 lines are missing. Anyone having an idea what might be the reason?

In addition, my build process consists of three processes which cannot run in parallel (cleaning up, compiling and linking). Would it be feasible to add the "standard_i/o_flag" feature to the

RunWait ( "filename" [, "workingdir" [, flag]] )

command such that one does not have to check for other processes making it easily possible to run such a sequence and still redirect the output via StdoutRead?

THX

[w0uter]

that wouldnt make sense.

runwait waits till the process closed and then continues.

so you would run a program.

its running > it finished > it exits

and AFTER it exits you begin to talk to it.

the best would be IMO to check when the process exits yourself.

(aka your code)

and then continue.

hope you got my point. im tired.

[DaveF]

However, for some larger projects the ouput suddenly stops towards the end of the linking process, i.e. the last ~30 lines are missing. Anyone having an idea what might be the reason?

I don't see any reason from the code above. You're welcome to post the whole script if you're willing/able to do so.

In case you don't have the entire example script the above was based on it can be found here.

Would it be feasible to add the "standard_i/o_flag" feature to the

RunWait ( "filename" [, "workingdir" [, flag]] )

command such that one does not have to check for other processes making it easily possible to run such a sequence and still redirect the output via StdoutRead?

Not sure that I understand the question. There's not a communal space that all child standard output goes to, each child process has its own pipe that it writes its STDOUT output to, and the StdoutRead function lets you connect to that pipe and read what's been written.

It's like each child process has its own little tank of data its output goes to and you can connect plumbing to it if you want to. In a DOS box there's default plumbing that dumps everything to the reservoir of the console screen unless you pipe it or redirect it yourself. In AutoIt you can read what you want from each child process or ignore some or read them out of order if you wish.

[Guest vzb]

I don't see any reason from the code above. You're welcome to post the whole script if you're willing/able to do so.

In case you don't have the entire example script the above was based on it can be found here.

Posting my original script wouldn`t make much sense since you need a special sw tool environment to reproduce the problem. However, I played with your example and found that replacing

$ourProcess = Run("ping autoitscript.com", @SystemDir, @SW_HIDE, 2)

with something like

$WorkingDir = "D:\arch\scripts"
$ourProcess = Run(@ComSpec & " /c" & 'perl loop.pl', $WorkingDir, @SW_HIDE,2)

where loop.pl is the following simple Perl script

#!perl -w
#
for ($i = 1; $i <= 2000; $i++)
{
    print "We're at index $i.\n";
}

produces a similar result. The output in $eOutput looks as follows

...

We're at index 1407.

We're at index 1408.

We're at index 1409.

We're at index 1410.

We're at index 1411.

We're at index 1412.

We're at index 1413.

We're at index 1414.4

[w0uter]

try it like:

$WorkingDir = "D:\arch\scripts"
$ourProcess = Run(@ComSpec & " /c" & 'perl loop.pl', $WorkingDir, @SW_HIDE,2)

$line = ''

While Not @error
    $line &= StdoutRead($ourProcess)
Wend

ConsoleWrite($LINE & @LF)

[DaveF]

@w0uter, you're only going to write the content of the last read with your code recommendation, because you're overwriting $line on each pass of the While loop.

@vzb, there's something wrong with that GUI example; using your example Perl script I get the same results you posted (the last character of "4" is an artifact of the problem, not a final floating-point index of 1414.4 which really freaked me out) or similar incomplete output with a formatted output string. Interestingly, if I just output the index digits (about 5kb of output) it does print the whole thing, so the problem appears with more than 10-20kb of output, which is why I never got it with my ping example.

Using the most simplistic test of StdoutRead:

$ourProcess = Run(@ComSpec & " /c" & 'perl "' & @ScriptDir & '\loop.pl"', @ScriptDir, @SW_HIDE,2)

While 1
    $line = StdoutRead($ourProcess)
    If @error = -1 Then ExitLoop
    ConsoleWrite($line)
WEnd

...I got the full output every time, so again I'm saying it's a flaw in the GUI example script.

DOH. Wake up, Fulgham. @vzb it's maxing-out the buffer in the edit box. Cut-and-paste the output from the edit box into notepad and save it as a text file, then check the size, you'll see it's exactly 32kb.

Edited July 17, 2005 by DaveF

[w0uter]

@w0uter, you're only going to write the content of the last read with your code recommendation, because you're overwriting $line on each pass of the While loop.

$line &= StdoutRead($ourProcess)

[DaveF]

Ah, sorry, @w0uter, as I said I wasn't performing at 100%...

[Guest vzb]

Hmmm, the posts above lead me to my next question:

How can you use StdoutRead and GUICtrlSetData for an edit ctrl and get around the 32kb limit?

[DaveF]

Hmmm, the posts above lead me to my next question:

How can you use StdoutRead and GUICtrlSetData for an edit ctrl and get around the 32kb limit?

You can't within the scope of AutoIt's built-in functionality. If you have the time and will to do so, you could read the MSDN docs on the Win32 edit control, specifically the "The Text Buffer" section, and see what might be done using AutoIt's DLLCall and (beta) DLLStruct functionality to make calls to the underlying Win32 API to allocate a larger buffer and assign it to the edit control.

[Guest vzb]

You can't within the scope of AutoIt's built-in functionality. If you have the time and will to do so, you could read the MSDN docs on the Win32 edit control, specifically the "The Text Buffer" section, and see what might be done using AutoIt's DLLCall and (beta) DLLStruct functionality to make calls to the underlying Win32 API to allocate a larger buffer and assign it to the edit control.

<{POST_SNAPBACK}>

Thanks, very helpful link. Following the explanation given here, I just added

Dim $EM_SETLIMITTEXT = 0x00C5
Dim $EditBufSize = WhateverSizeYouWant
...
$eOutput = GuiCtrlCreateEdit("", 0, 10, 423, 260, BitOR($ES_WANTRETURN, $WS_VSCROLL, $WS_HSCROLL, $ES_AUTOVSCROLL, $ES_AUTOHSCROLL, $ES_READONLY))
; Increase size of Edit control $eOutput
GUICtrlSendMsg ($eOutput, $EM_SETLIMITTEXT, $EditBufSize, 0)
...

to the example script - works fine for me now.

[w0uter]

maby it is an idee to let people set the max size in a parameter of GuiCtrlCreateEdit.

[DaveF]

Dim $EM_SETLIMITTEXT = 0x00C5
Dim $EditBufSize = WhateverSizeYouWant
...
$eOutput = GuiCtrlCreateEdit("", 0, 10, 423, 260, BitOR($ES_WANTRETURN, $WS_VSCROLL, $WS_HSCROLL, $ES_AUTOVSCROLL, $ES_AUTOHSCROLL, $ES_READONLY))
; Increase size of Edit control $eOutput
GUICtrlSendMsg ($eOutput, $EM_SETLIMITTEXT, $EditBufSize, 0)
...

to the example script - works fine for me now.

Fearsome. I'm pleased for you that it works, but by the text of the same article it doesn't seem that it should, 32kb is the default size of the entire available text buffer, so a call to enlarge it shouldn't do anything; I'll have to defer to @JPM as to why it works...

[Edit] Ah, read throught the EM_SETLIMITTEXT info page again, seems like that it will indeed dynamically resize the buffer. Cool. This is at odds with the description on the previous edit control page, but *shrug*. Typical for Microsoft documentation.

Edited July 20, 2005 by DaveF