Waiting for Setup under NT
stan
install acrobat reader. To do so, I run the Acrobat setup (which was
created using InstallShield (version 3 I think) silently with the -SMS
parameter.
I then use WaitForInputIdle for Setup to finish initializing. Then I use
GetExitCodeProcess inside a loop to wait for Setup's exit code to be
different than STILL_ACTIVE. When it is the loop breaks and my program
continues.
This works fine under Windows 95 and 98. Under NT 4.0, however, it doesn't
work. Setup launches, WaitForInputIdle seems to successfully wait until it
initializes, but then the loop breaks right away.
It seems that either the -SMS switch is not working under NT or setup
returns something other than STILL_ACTIVE even though it is still active.
Does anybody have any ideas why this doesn't work under NT? Or does anybody
have a different approach to waiting for the Acrobat setup procedure to
complete?
thanks
Stan Marshall
Investment Horizons, Inc.
st...@investmenthorizons.com
Stefan Krueger
base article Q101633 will help you.
--
Stefan Krueger
Independent Setup Consultant
// InstallSite - Resources for setup developers
// http://www.installsite.org (primary site - USA)
// http://installsite.sw.com.sg (mirror site - Singapore)
My reply-to address is invalid to avoid spam.
If you are looking for individual assistance,
like e-mail support, please mail to
in...@installsite.org for support options.
stan <st...@fyi.net> schrieb in im Newsbeitrag:
374c0...@news.installshield.com...
Ken McKinney
not returning STILL_ACTIVE) in my installer! We must be leading parallel
lives...
In my case, GetExitCodeProcess was returning 0, which means that the API
call failed... I called GetLastError and it returned a 127, which means "the
specified procedure could not be found". I'm not sure why this is the
case... the sub-install I spawned off is still running and the process
handle which I passed to GetExitCodeProcess is the same one that
CreateProcess.. returned in it's PROCESS_INFORMATION structure.
Anyway, I am still actively investigating this... if you figure it out,
please let me know... and I'll do likewise.
Ken McKinney
Depository Trust Company
ke...@best.com
stan wrote in message <374c0...@news.installshield.com>...
Ken McKinney
Just wanted to clarify things... I misinterpreted the GetExitCodeProcess
documentation...
It looks like the API call succeeds, because the BOOL it returns is set to
1, not 0. The exit code
which it is returning in the 2nd parameter is 0, though, so I still have the
aforementioned problem.
Ken
Ken McKinney wrote in message <374c6...@news.installshield.com>...
Ken McKinney
It turns out that my code works (GetExitCodeProcess returns STILL_ACTIVE
when it should) when I substitute notepad.exe for the spawned subinstall.
I'm thinking now that the problem is that the spawned subinstall is a 16-bit
application and that somehow GetExitCodeProcess doesn't recognize that it is
still running because of the way it is launched (via NTVDM.EXE). I'm
currently trying to figure out how to get GetExitCodeProcess to work
correctly when monitoring the status of a handle returned by createprocess
when createprocess is used to launch a 16 bit application.
InstallShield, do you have any advice? Is this why LaunchAppAndWait
sometimes doesn't wait?
Ken McKinney
bob_hu...@my-deja.com
Oddly enough, I am also grappling with this very
same problem....
I have noticed that when you call CreateProcess()
the PROCESS_INFORMATION structure gets a valid
Process ID but does not get a valid Process
Handle.
I've even tried calling OpenProcess() using the
Process ID returned by CreateProcess(), but that
also returns a 0 for the Process Handle.
Since GetExitCodeProcess() requires a valid
Process Handle, this would explain why it doesn't
appear to be working.
What I don't know, is why CreateProcess() is
returning a 0 for the Process Handle.
Bob Hutchings
rhutc...@independent-telecom.com
In article <374d9...@news.installshield.com>,
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Bob Hutchings
another look at it this morning, and discovered I was, in fact, getting
a Process Handle, but no Process ID.
So I scrapped my OpenProcess() call and instead dropped
PROCESS_INFORMATION.hProcess into a call to WaitForSingleObject().
This time my app just sat there and waited forever...
(I'd set the timeout to INFINITE just for the sake of testing.)
In article <7im21r$eic$1...@nnrp1.deja.com>,
bob_hu...@my-deja.com wrote:
>
>
> Oddly enough, I am also grappling with this very
> same problem....
>
> I have noticed that when you call CreateProcess()
> the PROCESS_INFORMATION structure gets a valid
> Process ID but does not get a valid Process
> Handle.
>
> I've even tried calling OpenProcess() using the
> Process ID returned by CreateProcess(), but that
> also returns a 0 for the Process Handle.
>
> Since GetExitCodeProcess() requires a valid
> Process Handle, this would explain why it doesn't
> appear to be working.
>
> What I don't know, is why CreateProcess() is
> returning a 0 for the Process Handle.
>
> Bob Hutchings
> rhutc...@independent-telecom.com
--
Bob Hutchings
Consulting Engineer
Independent Telecom
rhutc...@independent-telecom.com
Bob Hutchings
CreateProcess( NULL, lpCmdLine, NULL, NULL, FALSE, 0, NULL,
lpcSourceDir, &StartupInfo, &ProcessInfo );
while ( TRUE )
{
GetMessage( &MsgInfo, NULL, 0, 0 );
dwExitCode = WaitForSingleObject( ProcessInfo.hProcess, 1000 );
if ( dwExitCode == WAIT_OBJECT_0 ) { break; }