 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
 Posted: Mon May 30, 2005 9:03 am Post subject: |
 |
|
Updated to version 3.1.2
- tweaked RunReturn function
- Added a new function (RunWEx) to allow StdInput, StdOutput, StdError
RunWEx(CMD, CMDdir, CMDin, CMDout, CMDerr)
- CMD - the console program/command to execute (str)
- CMDdir - Future Use (working directory - not currently functional) (str)
- CMDin - StdInput String (str)
- CMDout - the variable used to store StdOutput output (str)
- CMDerr - the variable used to store StdError output (str)
= If the function fails, the return value is zero
Please report any bugs if found. Comments, suggestions welcome...
Finstr.exe StdInput Example:
| Code: | ; cmdret - Findstr.exe test script (dll version 3.1.2 or greater required)
;
; RunWEx Function
; StdIn, StdOut
Gui, Add, Edit, x6 y10 w380 h150 vTextIn, ;
Gui, Add, Edit, x6 y170 w270 h20 vFindit, ;
Gui, Add, Button, x286 y170 w100 h20 +Default gGoFind, Find String
Gui, Show, h203 w399, findstr CMDret test
NULL=
CMDout=
CMDerr=
Return
GoFind:
Gui, Submit, NoHide
Findit = "%Findit%"
Findit := "findstr.exe /I /C:" Findit
Ret := RunWaitEx(Findit, NULL, TextIn, CMDout, CMDerr)
MsgBox, Return Value: %Ret% `r`n`r`nStdError: `r`n%CMDerr%`r`nStdOutput: `r`n%CMDout%
Return
RunWaitEx(CMD, CMDdir, CMDin, ByRef CMDout, ByRef CMDerr)
{
VarSetCapacity(CMDOut, 100000)
VarSetCapacity(CMDerr, 100000)
RetVal := DllCall("cmdret.dll\RunWEx", "str", CMD, "str", CMDdir, "str", CMDin, "str", CMDout, "str", CMDerr)
Return, %RetVal%
}
GuiClose:
ExitApp |
Test script:
- Enter lines of text in the Edit control above
- Enter a search string in the Edit control below
- Click the 'Find String' button to retrieve results
 |
|
| Back to top |
|
 |
JBensimon
Joined: 16 Nov 2004
Posts: 130
Location: New York
|
| Posted: Mon May 30, 2005 4:12 pm Post subject: WOW!! |
|
|
corrupt, my hero! 
This looks amazing -- I'll download the new version and play with the new function some time today and report back. As Chris said once before, your DLL is becoming irresistible!
Thanks for your efforts.
Jacques. |
|
| Back to top |
|
|
JBensimon
Joined: 16 Nov 2004
Posts: 130
Location: New York
|
| Posted: Mon May 30, 2005 6:11 pm Post subject: It works! |
|
|
Well, the new RunWEx function certainly works as advertised -- great job!
Question: Is the command line argument parsed in the same way as AHKparses the first RunWait argument? i.e. does it recognize the .exe extension as the end of the executable part (without the need for double-quotes) and whatever follows as the executable's command line parameters, or are double-quotes required around the executable's path when it contains spaces? [This question is the reason I was thinking of separating out the command line parameters as a separate function parameter, to avoid ambiguity without the need for double-quotes.]
Did you say something about making the DLL's code available? I'm still amazed at the small size of the DLL, even with its 4 separate functions  
Thanks again.
Jacques. |
|
| Back to top |
|
|
JBensimon
Joined: 16 Nov 2004
Posts: 130
Location: New York
|
| Posted: Mon May 30, 2005 6:15 pm Post subject: |
|
|
Oh, one more question I forgot to ask:
What is the meaning of the RunWEx call's return value? It sometimes seems to reflect the size of the StdOut output, but you stated that 0 should be interpreted as some sort of failure. Is the launched command's exit code (ErrorLevel) lost?
Jacques. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Wed Jun 01, 2005 4:53 am Post subject: |
|
|
Sorry for the delayed response. ( hard drive issues  again... )
| JBensimon wrote: | corrupt, my hero!
This looks amazing -- I'll download the new version and play with the new function some time today and report back. As Chris said once before, your DLL is becoming irresistible!
Thanks for your efforts.
Jacques. |
Thanks
| JBensimon wrote: | | Question: Is the command line argument parsed in the same way as AHKparses the first RunWait argument? i.e. does it recognize the .exe extension as the end of the executable part (without the need for double-quotes) and whatever follows as the executable's command line parameters, or are double-quotes required around the executable's path when it contains spaces? |
AFAIK the command line argument should be compatible with the way you would run the program from a cmd prompt. Please let me know if anything doesn't work as expected.
| JBensimon wrote: | | Did you say something about making the DLL's code available? I'm still amazed at the small size of the DLL, even with its 4 separate functions |
Yes, that is planned for the near future . The current size could probably be reduced a bit more. Yes, the functions are currently separate. I have left them this way to allow easier modification and for backwards compatibility. This way I can add new functions for testing without affecting the stability of functions from a previous version.
| JBensimon wrote: | | What is the meaning of the RunWEx call's return value? It sometimes seems to reflect the size of the StdOut output, but you stated that 0 should be interpreted as some sort of failure. Is the launched command's exit code (ErrorLevel) lost? |
At the moment it returns the number of characters returned in StdOut + characters in StdErr + 1 or 0 if the command line fails (nothing particularily useful...). GetLastError may give a bit more info if the return value is 0. I'll look into returning the exit code instead. Thanks. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Thu Jun 02, 2005 3:49 am Post subject: |
|
|
| Note: only 32 bit console applications will currently work with the dll version of CMDret (v3.1.2 or lower). Calls that require command.com will likely not produce any output and may crash. The next version should hopefully fix this issue. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Thu Jun 02, 2005 5:20 am Post subject: |
|
|
Updated download: version 3.1.2
- Added cmdstub.exe to the download to support 16 bit console applications
| Code: | ; CMDret DLL version 3.1.2 (or greater) required
; cmdstub.exe required if using command.com
ret1 := CMDret("cmdstub.exe command.com /C set")
MsgBox, %ret1%
CMDret(CMD)
{
VarSetCapacity(StrOut, 100000)
RetVal := DllCall("cmdret.dll\RunReturn", "str", CMD, "str", StrOut)
Return, %StrOut%
} |
| Code: | ; cmdret - Find.exe test script (dll version 3.1.2 or greater required)
; Win9.x test - cmdstub.exe required
;
; RunWEx Function
; StdIn, StdOut
Gui, Add, Edit, x6 y10 w380 h150 vTextIn, ;
Gui, Add, Edit, x6 y170 w270 h20 vFindit, ;
Gui, Add, Button, x286 y170 w100 h20 +Default gGoFind, Find String
Gui, Show, h203 w399, find - CMDret test
NULL=
CMDout=
CMDerr=
Return
GoFind:
Gui, Submit, NoHide
Findit = "%Findit%"
Findit := "cmdstub.exe find.exe /I " Findit
Ret := RunWaitEx(Findit, NULL, TextIn, CMDout, CMDerr)
MsgBox, Return Value: %Ret% `r`n`r`nStdError: `r`n%CMDerr%`r`nStdOutput: `r`n%CMDout%
Return
RunWaitEx(CMD, CMDdir, CMDin, ByRef CMDout, ByRef CMDerr)
{
VarSetCapacity(CMDOut, 100000)
VarSetCapacity(CMDerr, 100000)
RetVal := DllCall("cmdret.dll\RunWEx", "str", CMD, "str", CMDdir, "str", CMDin, "str", CMDout, "str", CMDerr)
Return, %RetVal%
}
GuiClose:
ExitApp |
Test second script:
- Enter lines of text in the Edit control above
- Enter a search string in the Edit control below
- Click the 'Find String' button to retrieve results
Please let me know if any bugs are found using this method with Win9.x systems. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Thu Jun 02, 2005 11:59 am Post subject: |
|
|
Looks good. In case you ever need to have the variable's memory size unrestricted, the following approach should work:
1) The DLL allocates dynamic memory, enlarging as needed to fit the text it retrieves.
2) The DLL returns the address of that memory along with the length of its contents.
3) The script uses VarSetCapacity to set the indicated size, then uses lstrcpy() to copy the text from the address into the variable.
I forget exactly how dynamic memory works in DLLs: If the memory vanishes when the DLL is unloaded, you would have to go back to using LoadLibrary and FreeLibrary. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Sat Jun 04, 2005 4:50 am Post subject: |
|
|
| Chris wrote: | Looks good. In case you ever need to have the variable's memory size unrestricted, the following approach should work:
1) The DLL allocates dynamic memory, enlarging as needed to fit the text it retrieves.
2) The DLL returns the address of that memory along with the length of its contents.
3) The script uses VarSetCapacity to set the indicated size, then uses lstrcpy() to copy the text from the address into the variable.
I forget exactly how dynamic memory works in DLLs: If the memory vanishes when the DLL is unloaded, you would have to go back to using LoadLibrary and FreeLibrary. |
That sounds like it might work nicely with the RunRedirect function. Thanks . Another method that should currently work ok for programs/commands that should produce the same output if run twice in a row (but will take longer...) , would be to call the function without the string variables first then use the return value of the function to set the size of the string variable.
| Code: | ; CMDret DLL version 3.1.2 (or greater) required
; cmdstub.exe required if using command.com
ret1 := CMDret("cmdstub.exe command.com /C set")
MsgBox, %ret1%
CMDret(CMD)
{
RetVal := DllCall("cmdret.dll\RunReturn", "str", CMD, "str", "")
VarSetCapacity(StrOut, %RetVal%)
RetVal := DllCall("cmdret.dll\RunReturn", "str", CMD, "str", StrOut)
Return, %StrOut%
} |
Another method that should currently work ok if the return size is unknown would be to use the RunInControl function to output to and edit style control (optionally hidden). If a RichEdit control is used (and Extended) a couple of Gig of output should be possible . |
|
| Back to top |
|
|
JBensimon
Joined: 16 Nov 2004
Posts: 130
Location: New York
|
| Posted: Sat Jun 04, 2005 8:14 pm Post subject: RichEdit control? |
|
|
| corrupt wrote: | | ... RichEdit control ... |
There isn't a RichEdit control option in AutoHotkey GUIs, is there? I'd hate to have missed that capability (which would be great for "message of the day"-type applications, if it had a Read-Only option like Edit controls do, and many other purposes).
Jacques. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Sat Jun 04, 2005 8:24 pm Post subject: |
|
|
| Not yet, but it's on the list. |
|
| Back to top |
|
|
Rabiator
Joined: 17 Apr 2005
Posts: 265
Location: Sauerland
|
| Posted: Sun Jun 05, 2005 8:53 pm Post subject: |
|
|
| corrupt wrote: | AFAIK the command line argument should be compatible with the way you would run the program from a cmd prompt. Please let me know if anything doesn't work as expected.
|
Is it possible to get the errorlevel of a program called with RunWEx?
(I wrote a small console application that uses the RunWEx function of CMDRet, which works excellent. The program uses stderr and stdout to return status and values to the script, and RunWEx separates these streams, very well.
But my program should also run in the command line environment, which does not separate stderr and stdout - they get mixed. Therefore I'd like to return the status via errorlevel rather than via stderr.) |
|
| Back to top |
|
|
JBensimon
Joined: 16 Nov 2004
Posts: 130
Location: New York
|
| Posted: Sun Jun 05, 2005 9:30 pm Post subject: StdErr fro command line... |
|
|
| Quote: | | my program should also run in the command line environment, which does not separate stderr and stdout - they get mixed |
If you're running the program in the command line environment of Windows NT/2000/XP/2003, you can use the "2>" syntax to redirect error output and separate it from standard output, as in
| Code: | | Program parameters >StdOut.txt 2>StdErr.txt |
Jacques. |
|
| Back to top |
|
|
corrupt
Joined: 29 Dec 2004
Posts: 2391
|
| Posted: Sun Jun 05, 2005 10:29 pm Post subject: |
|
|
| Rabiator wrote: | | But my program should also run in the command line environment, which does not separate stderr and stdout - they get mixed. Therefore I'd like to return the status via errorlevel rather than via stderr.) |
Returning errorlevel is planned (possibly next release). Thanks . |
|
| Back to top |
|
|
Rabiator
Joined: 17 Apr 2005
Posts: 265
Location: Sauerland
|
| Posted: Tue Jun 07, 2005 7:06 am Post subject: |
|
|
| JBensimon wrote: | | Quote: | | my program should also run in the command line environment, which does not separate stderr and stdout - they get mixed |
If you're running the program in the command line environment of Windows NT/2000/XP/2003, you can use the "2>" syntax to redirect error output and separate it from standard output, as in
| Code: | | Program parameters >StdOut.txt 2>StdErr.txt |
|
Thanks for the hint!  I am a Win98 dinosaur.
| corrupt wrote: | | Returning errorlevel is planned (possibly next release). Thanks . |
I'm looking forward to this. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
