ExecWait --> then pass text to launched exe...

Archive: ExecWait --> then pass text to launched exe...

Jnuw
2nd September 2004 02:02 UTC

ExecWait --> then pass text to launched exe...
Hello all.

I'm very new to NSIS, but I already love it. I seemed to be stumped on my current challenge though. I am using ExecWait to launch an exe that will automatically do some database editing. Currently this exe simply requires a user to enter a username and password. I would like to eliminate that user touch, and after launching the exe, pass in the text: <username><tab><password><enter> . Can someone point me in the right direction? Thanks much all.

Jnuw

Gurleen
2nd September 2004 07:10 UTC

What if you just pass the the parameters after the execWait
like this
ExecWait 'databaseHandler.exe username password'

WEll this thing works when you call execWait with .msi

ExecWait '${INSTALLERDLL}\msxml.msi /qn'

In the above command we are running msxml.msi with command line parameters . So you can pass the parameters to your program. Now it depends on your program how it handles these command line parameters.

Takhir
2nd September 2004 08:59 UTC

For DOS applications it is possible to launch application with redirected i/o . NSIS nsExec plugin hides console window and handles application's output. I also wrote a simple plugin using string parameter as stdin http://forums.winamp.com/showthread....ighlight=stdin
You can also set "Ignore default libs" in plugin project to decrease dll size (like this done in other plugins).

Jnuw
2nd September 2004 21:10 UTC

Thanks guys for the responses. Unfortunately this exe does not accept parameters, and is not a DOS app. I didn’t write it, and can’t change it to use parms. This is what it looks like:

http://webpages.charter.net/orum/1.jpg

So after launching it, I just need to send or pipe (like in a DOS batch file) a user name, then tab down and enter the password and hit enter. Would SendMessage work for this? Thanks all.

Comm@nder21
3rd September 2004 15:40 UTC

yes, sendmessage would work.

Takhir
3rd September 2004 16:29 UTC

MSDN declares the only message for interprocess communication - WM_COPYDATA (Platform SDK/Windows Base Services/Interprocess Communication). This should work always. But in real life other messages work too (but without any warranties && with some security limitations && inside the same virtual desktop) - you can find few samples of WM_CLOSE usage in this forum.

Jnuw
3rd September 2004 16:36 UTC

Originally posted by Comm@nder21
yes, sendmessage would work.

Thanks Comm@ander21. The exe I’m working with, pictured above, is called Mod.exe. I'm having some trouble figuring out the syntax of the send message command. Could someone lend a hand please?

SendMessage HWND msg wparam lparam [user_var(return value)] [/TIMEOUT=time_in_ms]

I read that "HWND" is the Windows Handle, which in this case would be Mod.exe. Past that I’m not sure how to pass the username, then a tab, then the password, then an <enter> to the exe. Any advice would be appreciated, thanks all.

Thanks.
Jnuw

Jnuw
29th September 2004 21:57 UTC

Bump. Any know the syntax of the send message command? Thanks.

kichik
30th September 2004 09:50 UTC

The window handle is not Mod.exe. You can get the window handle using FindWindow. Once you got the main window's handle, you'd need to find the text field handles. To do that, you'd use GetDlgItem. If it's not a dialog, you'd need FindWindow again.

Once you have the text fields' window handles you can send them WM_SETTEXT:

!include WinMessages.nsh
SendMessage $TEXT_HWND ${WM_SETTEXT} 0 "STR:some text"

Then, once the text fields are full, you'd want to press the button. Assuming that is a dialog and that the continue button is the OK button, you'd send the main window a WM_COMMAND message:

!include WinMessages.nsh
SendMessage $MAIN_HWND ${WM_COMMAND} 1 0

A few possible problems:

You can't use ExecWait because the script will not continue to execute all of the SendMessage instructions until that program is closed.
If you use Exec, you can't know for sure if the window has already been created and destroyed. Every loop you write might end up an infinite loop.

To work around those, you need to write a plug-in or some System.dll code that will give you the process handle so you can wait on it until the window is created.

The best solution for this is to find a way to pass those parameters in a sane way. If you can't find one, you might want to try AutoIt first.

Jnuw
30th September 2004 15:17 UTC

kichik, thank you so much for your explanation. You bring up some very good points there as far as possible problems. I will check out these options, and post back with the results. Thanks again.