I'm back again with an "autoupdater" question. I have an application
that is made up of a bunch of stacks. Each stack as a custom property
cstkVersion that carries the current version number of that stack. On
my server, I have the latest versions of all the stacks and a text file
that contains lines of the form:
stackfilename,stackversion
I have one "get the ball rolling stack" that checks itself against the
latest version and then downloads the latest version if the versions are
different. This part seems to be working fine although I do require the
user to quit the program and restart it if it has been updated. This
whole process is started up by a stand-alone that launches this first
stack and is simple enough that the stand-alone should only require
changing when the engine changes.
Now to the "real" problem/question: As I'm going through my text file of
stack names/versions, I have to check the cstkVersion property of each
stack on the user's hard drive against the version listed in the text
file. In order to read the property, the stack has to be loaded into
memory. My problem is how to I get rid of this in-memory copy and
replace it with the new version (assuming that I had to download a new
version)?
Is it as simple as:
if tVersionUpdated then
stop using tCurrentStack
end if
and then when I really need the stack, another "start using stack ..." ?
The documentation for "reload stack" indicates that this is used to
prevent two stacks with the same name being loaded at the same time. If
I don't pass the message on, I'll have the old and the new stack in
memory at the same time. I understand how this might cause problems.
If I pass the message on, what happens? Does it purge the current
version from memory and then load the new one? Does it throw and
error? Does it go ahead and load the new version too and then decide
which one messages will be sent to?
Is there another command or function that will purge the stack currently
in memory and reload the new and improved version from disk?
Thanks for any clarity you can provide.
len morgan
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
