AutoHotkey Community
It is currently May 26th, 2012, 1:39 pm

View unanswered posts | View active topics


Board index » General » Utilities

All times are UTC [ DST ]



Post new topic Reply to topic  Page 3 of 11
  [ 164 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 11  Next
  Print view | E-mail friend Previous topic | Next topic 
Author Message
corrupt
 Post subject:
PostPosted: May 30th, 2005, 9:03 am 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2542
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

:)


Report this post
Top
 Profile  
Reply with quote  
JBensimon
 Post subject: WOW!!
PostPosted: May 30th, 2005, 4:12 pm 
Offline

Joined: November 16th, 2004, 6:38 am
Posts: 153
Location: New York
corrupt, my hero! :D

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.


Report this post
Top
 Profile  
Reply with quote  
JBensimon
 Post subject: It works!
PostPosted: May 30th, 2005, 6:11 pm 
Offline

Joined: November 16th, 2004, 6:38 am
Posts: 153
Location: New York
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.


Report this post
Top
 Profile  
Reply with quote  
JBensimon
 Post subject:
PostPosted: May 30th, 2005, 6:15 pm 
Offline

Joined: November 16th, 2004, 6:38 am
Posts: 153
Location: New York
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.


Report this post
Top
 Profile  
Reply with quote  
corrupt
 Post subject:
PostPosted: June 1st, 2005, 4:53 am 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2542
Sorry for the delayed response. ( hard drive issues :( again... )

JBensimon wrote:
corrupt, my hero! :D

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.


Report this post
Top
 Profile  
Reply with quote  
corrupt
 Post subject:
PostPosted: June 2nd, 2005, 3:49 am 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2542
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.


Report this post
Top
 Profile  
Reply with quote  
corrupt
 Post subject:
PostPosted: June 2nd, 2005, 5:20 am 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2542
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.


Report this post
Top
 Profile  
Reply with quote  
Chris
 Post subject:
PostPosted: June 2nd, 2005, 11:59 am 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
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.


Report this post
Top
 Profile  
Reply with quote  
corrupt
 Post subject:
PostPosted: June 4th, 2005, 4:50 am 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2542
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 :) .


Report this post
Top
 Profile  
Reply with quote  
JBensimon
 Post subject: RichEdit control?
PostPosted: June 4th, 2005, 8:14 pm 
Offline

Joined: November 16th, 2004, 6:38 am
Posts: 153
Location: New York
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.


Report this post
Top
 Profile  
Reply with quote  
Chris
 Post subject:
PostPosted: June 4th, 2005, 8:24 pm 
Offline

Joined: March 2nd, 2004, 3:36 pm
Posts: 10720
Not yet, but it's on the list.


Report this post
Top
 Profile  
Reply with quote  
Rabiator
 Post subject:
PostPosted: June 5th, 2005, 8:53 pm 
Offline

Joined: April 17th, 2005, 7:47 pm
Posts: 289
Location: Sauerland
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.)


Report this post
Top
 Profile  
Reply with quote  
JBensimon
PostPosted: June 5th, 2005, 9:30 pm 
Offline

Joined: November 16th, 2004, 6:38 am
Posts: 153
Location: New York
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.


Report this post
Top
 Profile  
Reply with quote  
corrupt
 Post subject:
PostPosted: June 5th, 2005, 10:29 pm 
Offline
User avatar

Joined: December 29th, 2004, 1:28 pm
Posts: 2542
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 :) .


Report this post
Top
 Profile  
Reply with quote  
Rabiator
 Post subject:
PostPosted: June 7th, 2005, 7:06 am 
Offline

Joined: April 17th, 2005, 7:47 pm
Posts: 289
Location: Sauerland
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! :idea: I am a Win98 dinosaur. :)

corrupt wrote:
Returning errorlevel is planned (possibly next release). Thanks :) .

I'm looking forward to this. :D


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 3 of 11
  [ 164 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 11  Next

Board index » General » Utilities

All times are UTC [ DST ]

Who is online

Users browsing this forum: No registered users and 0 guests

You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group