Running a generated install while app is running

[NewsArchive]

Running an installer (update) while an app is active, precludes installation,

but there is no error message.
How does one warn about (and optionally shut down) the running app?

Sim

[NewsArchive]

Sim,

> Running an installer (update) while an app is active, precludes
> installation, but there is no error message.
> How does one warn about (and optionally shut down) the running app?

The standard way to handle this is to use the "Detect Active Application..."
script function. The check can be done via the File Name -or- Mutex -or-
Mutex (SYNCHRONIZE) -or- Window's Title.

If the application is active, you can ask the user to shut it down. You can
also use "Terminate Active Application..." to programmatically terminate the
application from your installer, but this is not recommended.

BTW, do the above active application check in a LOOP to make sure the user
really closed it down. Similar to this:

http://www.lindersoft.com/forums/showthread.php?p=10385#post10385

Friedrich

[NewsArchive]

Hi Friedrich,

> The standard way to handle this is to use the "Detect Active
> Application..."
> script function. The check can be done via the File Name -or- Mutex -or-
> Mutex (SYNCHRONIZE) -or- Window's Title.

Thanks for the tip. That's really helpful. I'll use that in our application
script.

Geoff

[NewsArchive]

Friedrich,

>If the application is active, you can ask the user to shut it down. You can
>also use "Terminate Active Application..." to programmatically terminate the
>application from your installer, but this is not recommended.

asking the user to shut sown - this is mainly meant for a single instance of
the install, or?

This would not have any effect if the program is run on some other clients
across the network, I would assume.

For a network-wide notification I use NetCloseApps in Nettalk. The Admin has
to run that tool prior to the install, of course.

http://www.capesoft.com/docs/nettalk/nettalk2.htm#Using_the_Other_NetTalk_Objects

bye
Wolfgang

[NewsArchive]

Hi Wolfgang,

> asking the user to shut sown - this is mainly meant for a single
> instance of the install, or?

Yes, this is for "workstation" updates (I don't think that Sim is doing
updates on a server).

To update an application on a server it's a good idea to use "Check In-use
File..." and/or "Check In-use Folder Tree..." on top of the detection
method.

Friedrich

[NewsArchive]

Hi Sim,

We have a number of different combinations of usage for our applications:
1) Stand-Alone (user runs a single app, processing done in the exe).
2) Simple install (application runs from a single PC, server runs as a
service or process in the background, UI apps run on demand). A derivative
of this is that some folk run the app from a shortcut on a different
machine.
3) Multiple install (server runs on one PC, and client apps installed on
multiple machines)

How we handle it:
1) Close down app and run install (with delay)
2) and 3) - The Server controls when to update, and communicates via 2
methods: 1) netsimple (normal close apps) and 2) writing to a data file
(which is only used to track the installation process). All apps open the
data file in share mode (and poll it every 60 secs). When the server is
ready to run the install it sends net close apps (which is not 100% reliable
as IT managers tend to be over protective of firewalls) and writes "Exit
now" to the updating data file and waits 'til it can open the updating data
file in deny all mode. The server is set to run the install at a particular
inactive time (normally around 2 am) - so in most cases this runs smoothly.
However there are exceptions, which we cater with as follows:

I've derived the abwindow.clw class to handle the event:closedown, and force
a cancel on open forms (yes - it's hard to believe, but folk down tools at
5pm even if they're half way into a form edit) - although in some cases it
waits for a process to finish before running the closedown.

We have a stub exe (in local mode) that runs the actual applications. The
stub exe's job simply checks the updating data file to see if it is allowed
to run the main exe or not (and warns the user if not, and keeps trying to
run). If the install is busy running - and someone runs a client
application, only the updated stub exe will not be installed immediately,
the main exes and dlls will all be installed, so you won't get a partial
install (how many of your users immediately reboot on the "Install needs to
reboot in order to complete" message?). The installer only installs
shortcuts to the stub exes, so folk will have to know to go into the actual
folder and run the random exe name from there to override the stub. They're
normally not that adventurous.

Once the server has run the update, it copies the latest install to the
\updates subfolder in the data folder, and the various clients will update
from there the next time they run.

There are some more details, but that's it in a nutshell.

HTH

Geoff

[NewsArchive]

Sim,

if your targets are larger networks with many users likely to have your program
running, you may have a look at in Nettalk were you find NetCloseApps. You
are able to enhance your program with that. I have a separate Admin.EXE for
this and other administrative chores.

The Admin, who runs the Install, can now see a list of machines, which have
running an instances of your main program.

He / She now can send a notification to all users to save their documents and
log off for the next XX minutes.

After a grace period the admin can kick out all remaining users who have fallen
asleep at their desktop.

Quite easy to implement.

Finding them in the docs is more difficult ;-)
http://www.capesoft.com/docs/nettalk/nettalk2.htm#Using_the_Other_NetTalk_Objects

Bye
Wolfgang

[NewsArchive]

Hi Friedrich,

Now I'm getting a little confused. If I get it right, Detect Active works on
the local pc only while Check In-Use works on the physical file whereever
that may be residing. Is that correct?

Then why do you suggest to add Check In-use _on top_ of Detect Active? I
would think it should be either or ... depending on whether you're working
in a network environment or not.
Please enlighten me <g>

Peter

[NewsArchive]

Hi Peter,

> Then why do you suggest to add Check In-use _on top_ of Detect Active?
> I would think it should be either or ... depending on whether you're
> working in a network environment or not.

It should even be enough to use only "Check In-use File..." in both server
and workstation scenarios. If an executable is located on a server and its
status is active (started on a workstation or running on the server) then a
"Check In-use File..." on that file will return "1" (file is in use). The
same is true for non-network environments. If the executable is running
then "Check In-use File..." returns "1".

Friedrich

[NewsArchive]

Thank you!
That did help (and for once, you didn't even ask <g>)

Peter

[NewsArchive]

> Thank you!
> That did help (and for once, you didn't even ask <g>)

<G> :-)

Friedrich

[NewsArchive]

Hi Friedrich,

Is it possible to use BOTH, by putting a "Terminate app" button, and a Loop
break thereafter?

Sim

[NewsArchive]

Hi Sim,

> Is it possible to use BOTH, by putting a "Terminate app" button,
> and a Loop break thereafter?

Yes, you can ask the user to close the app and then check again. If it is
still active, abort the install or try to terminate the app. First try it
gently, then the brutal way (kill) -- not recommended. But you can do it.
Then check again if the app is really inactive. You can do all this in one
big LOOP.

Friedrich

[NewsArchive]

Many thanks, Friedrich.

Sim

[NewsArchive]

>
> Many thanks, Friedrich.
>

You are welcome, Sim!

Friedrich