ive found several ways to handle this. all of them are app-specific,
unfortunately.
look for the _last_ file the installer creates and wait until it appears.
this depends on a reasonably regular setup across different systems.
holding a change notify object open on the %TEMP% dir and looking for the
creation and deletion of a directory like _ISTMP.DIR
look for the appearance of a particular key in the registry (usually the
last thing an install proggie does in the ones ive encountered.
make my own installer that doesnt suffer from the same problem.
my personal favourite:
use something like seagate (now veritas) wininstall to do the dirty work for
me. much simpler.
--
regards, dave
> -----Original Message-----
> From: John Pollock [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 29, 2000 3:09 PM
> To: Helberg Jens (QI/LBS1-Bue) *
> Cc: [EMAIL PROTECTED]
> Subject: RE: Installing 32-bit applications
>
>
> On Fri, 29 Dec 2000, Helberg Jens (QI/LBS1-Bue) * wrote:
>
> > You'd wait til the child process spawned by the setup
> program dies. There're
> > some modules which can retrieve the current running processes, i.e.
> > setupsup. Take the following sample as a skeleton:
>
> That may work in instances where the main process (setup) spawns a
> subprocess that controls all later processes. But it won't
> work in a case
> where the main process forks off a bunch of child processes, since the
> number of child processes may be variable and have different
> names, so how
> would you know which ones were associated with the parent?
>
> Speaking as someone who has run into this unfortunate problem, i would
> dearly love someone to have a ready-made answer to this. :)
>
> J
>
> _______________________________________________
> Perl-Win32-Admin mailing list
> [EMAIL PROTECTED]
> http://listserv.ActiveState.com/mailman/listinfo/perl-win32-admin
>
_______________________________________________
Perl-Win32-Admin mailing list
[EMAIL PROTECTED]
http://listserv.ActiveState.com/mailman/listinfo/perl-win32-admin
