AW: How do you handle an engine update for your app?

Tiemo Hollmann TB toolbook at
Mon Dec 1 12:01:57 EST 2008

Hello Dave,
your approach brought me another idea.
What about if I would always have two "launching" standalones one behind the
other. First one only to check and do the updates, calling the second
standalone and quitting. The second standalone is nothing else, as a carrier
of the standalone engine, splash screen and what else wanted and calls the
main stack.
If this works I could always update the newest engine with the second
standalone and the only thing what I can't do with this approach is to
update the first standalone. Assuming that I don't want to change anything
in the update procedure, this would be the easiest way.
Am I sure that this way, my main stack will be handled by the engine of the
second standalone, or would it still be handled by the engine of the first
Thank you

> -----Ursprüngliche Nachricht-----
> Von: use-revolution-bounces at [mailto:use-revolution-
> bounces at] Im Auftrag von Dave Cragg
> Gesendet: Montag, 1. Dezember 2008 16:45
> An: How to use Revolution
> Betreff: Re: How do you handle an engine update for your app?
> On 1 Dec 2008, at 13:17, Tiemo Hollmann TB wrote:
> > What are your approaches to organise this issue?
> Here is the rough outline of an approach I've used before.
> -- Build a standalone to act as the updater. The new "engine file" is
> contained in a custom property of this standalone.
> -- Have the current application download the updater standalone.
> (place it in a temp location.)
> -- Launch the updater standalone.
> -- Quit the current application.
> -- The updater standalone deletes the current application, installs
> the new one, and launches the new one. (Probably add a delay of a few
> seconds before deleting the current application so it has time to
> fully quit.)
> -- The updater application quits.
> -- In the new application, include a routine to delete files from the
> temp location, either at startup or shutdown.
> Possible problems:
> The user must have write permissions to the location where the
> application is to be installed. But as this also affects the original
> installation, it's probably not a problem. But you might want to only
> make the Update feature available to users with appropriate write
> permissions.
> There may be restrictions/warnings/etc. after downloading an
> executable. You probably should compress the Updater Standalone and
> decompress it in the temp location from within the current
> application. (That might not be enough.)
> This needs appropriate functionality in the current application. So if
> you want to update an application that is installed now, and it
> doesn't contain the appropriate functionality, you need another
> approach. ;-)
> Cheers
> Dave
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:

More information about the Use-livecode mailing list