Archive: ExecWait & rundll32


ExecWait & rundll32
i use ExecWait to launch a dll using rundll32.exe and the dialog that appears requires input from the user. however the installer will continue its work without waiting for the dialog to close. i know that rundll32.exe has finished its job and closed so is there any way to make the installer wait till the dialog box has closed?


Or rebuild to dll the close the dialog until the user "ends it".


i cannot do that as i am only incharge of the installer........my code is something like this

ExecWait "rundll32.exe dll_name.dll,FunctionName"

now i need to make the installer wait for the relevant details from the dialog box....... rebuilding the dll is not an option and even if it was it would take some time


I don't know much, is logic that if rundll.exe exits from the process before the dialog close, must be something wrong with the dll.
A temp solution that I can give you, is to use sleep function.
ExecWait finishes when rundll32 finishes, keep that in mind.


You can use the System plug-in to call that function instead of rundll32.exe. It should always wait for the function to return.


the problem is that the dll will return an inistalisation success message and cause the system plug in to close.... it is similar to the rundll32 problem i think. the guy who made the dll says it is vital to the program and that to help out he said that it resembles the following function call::

rundll32.exe user32.dll,LockWorkStation

i transalated it into the system plugin so i could get some idea of how it works but no luck. suggestions???

System::Call 'user32.dll::LockWorkStation(i, *i, t) i(.r0, r1, .r2) .r3'


Originally posted by Joel
must be something wrong with the dll.
ah if only it were that simple........:(

In that case, there's nothing you can do. The DLL must change or you must find something else to wait for. Maybe you can wait for the window it opens to close.


maybe i can use ::
FindWindow $0 '' 'Program Title'

but what will be the windows class???


You some sort of spy, like win32spy, to find that out. But be aware any solution like this could fail due to timing issues. The best solution would be to modify the DLL.