updating end user to new version??

[no1g8tor]

I was wondering what steps to take to set a "Check for Updates" in a menu option. I dont need to know how to set the actual menu item, just what I need to do when a user selects it.

ie. dowload and "install" the new version. I think I would need to upload it to a file server or my webserver but how can I tell it to goto there download it and put it in the right place.

I would like to bring up a small screen and progress bar with it.

the program will be in one .exe file.

Thanks so much.

[Janschenkel]

Check out the 'libURLdownloadToFile' command - it allows you to download a file on your server, identified by a URL, to a local file path.

The tricky parts:
- You can't just replace the .exe that is currently running
- The user may not have sufficient rights to write inside the Program Files directory
- And on Vista the file may well end up somewhere else in a Virtual Directory.

So all in all, it may be easier to just launch the browser to your download page and let the user download and run the installer from there.

Other than that, most 'self-updating' Revolution applications use the 'splash screen' approach. The executable is essentially just a tiny shell, which loads the first stack, which in turn does the rest of the initialization.

The 'Check for Updates' mechanism can then download newer versions of the files to a subdirectory in the All Users' Application Data directory, and you script your stacks such that they first take a look at the Application Data subdirectory and load the stack from there, rather than the Program Files subdirectory where your executable resides.

Hope this gave you some ideas,

Jan Schenkel.

[no1g8tor]

Jan,

Thanks for the reply, but could you give me an example of the method you described?

Other than that, most 'self-updating' Revolution applications use the 'splash screen' approach. The executable is essentially just a tiny shell, which loads the first stack, which in turn does the rest of the initialization.

Thank you

[Janschenkel]

The 'splash screen approach' is quite easy to accomplish:

1. Create two new stacks
- the first stack will become your executable -> name it "splash"
- the second stack your 'updatable' application -> name it "worker"

2. Put some artwork in your "splash" stack and set the script of the first card to

Code: Select all

on openStack
  wait 2 seconds  -- so people can see the artwork
  go stack "worker"
  hide me
end openStack

3. Put a button in your "worker" stack and set its script to

Code: Select all

on mouseUp
  answer "Are you sure you want to quit?" with "OK" or "Cancel"
  if it is "OK" then quit
end mouseUp

4. Now build a standalone from your "splash" stack. You will first have to enter the Standalone Application Settings - use 'Select inclusions' and make sure the 'Answer dialog' is added.

5. Drop a copy of your "worker" stack in the same directory as your executable.

Now when you doubleclick your executable, it will display the splash screen and after two seconds the worker stack comes up on screen. Use the button to quit your application. Congratulations, you have created your first 'stub' application.
Please not that the above example isn't all-inclusive: the 'splash' stack doesn't check for the actual presence of your 'worker' stack, the 'worker' stack dosn't properly quit if you just close the window, etc. But it should give you a pretty good idea

Going back to your 'Check for updates', you could put something like this in your 'worker' stack script

Code: Select all

on openStack
  load URL "http://www.example.com/version.txt" with message "VersionRead"
end openStack

constant kVERSION = "1.0.0"

on VersionRead
  put URL "http://www.example.com/version.txt" into tVersion
  if tVersion > kVERSION then
    answer "There is a newer version of MyApplication available online."
  end if
end VersionRead

From here you can extend your update logic: for instance, you could move it into a separate "update" stack to make it easier to replace individual parts.

Hope this gets you started,

Jan Schenkel.

[no1g8tor]

So just make an "update" standalone so when some clicks "Check for updates" I can have it check the version.

If so, have my application execute the "update application", close my main app then download the new exe to the current directory, launch the new exe and close the update app.

Is this correct?

Only one other thing, if the name of the new exe is the same as the old, should I have it rename the old app first before the download and then delete the rename after the dupdate?

Thanks so much

[Janschenkel]

There's no need to use multiple executables - the update can be done from within a single Revolution- standalone application.

If you try to replace existing .exe files, you are bound to run into user privilege problems - the user that is running your application may not have Administrator rights. So the goal of this splash screen variation is simple: your executable contains only a splash screen and the rest of your application is saved as separate .rev files in your executable's directory.

To get around the user privilege problems, you will want to download newer versions of your .rev files into the All Users' Application Data directory. And when you want to open a stack, first check if it exists in the Application Data directory, and if so, open that one instead of the file that's in your executable's directory.

If this all sounds too complicated, you can always just show an answer dialog box and optionally open the browser so the user can download a new installer.

Code: Select all

on VersionRead
  put URL "http://www.example.com/version.txt" into tVersion
  if tVersion > kVERSION then
    answer "There is a newer version of MyApplication available online." \
        with "Go to the website" or "Remind me later"
    if it begins with "Go" then
      launch URL "http://www.example.com/myappupdate.htm"
    end if
  end if 
end VersionRead

Or you can choose to adopt the GLX Application Framework, which takes care of a lot of these things for you. Here's the link:
http://www.bluemangolearning.com/develo ... mework.php

Jan Schenkel.

[rayjbenet]

Hi Jan - I've been using the splash screen approach for my distribution since the beginning (2003) and appreciate the clear explanation you've provided here.

I assume, from the size of the file, that the .exe contains the "kernel" of the application - i.e., the stuff the the Rev standalone builder needed to make an executable for the target platform.

So my question is this: whenever we change the release of Revolution that our standalone is built upon, it would _seem_ that it makes sense to replace the .exe part of the standalone executable as well. Is there something within the release notes or other documentation that would indicate when this _wouldn't_ be the case (for instance, if the new release of Rev provided new features for the Script Editor, it most likely wouldn't affect my standalone)?

Thanks for your insight.
Ray

[Janschenkel]

Hi Ray - glad to hear that my explanation is clear and hopefully of use to readers

You are correct that the splash screen .exe is a type of "kernel" containing all the functionality a Revolution application would need.

And the follow-up question obviously makes a lot of sense: how do we update this "kernel" in the field? Combine this with the fact that our friends at RunRev HQ move forward and do not back-port fixes to older versions, and you may find the need for such "kernel" updates from time to time as well.

The truth is: there is no easy answer for this particular problem. You could make your splash .exe a combination of an update checker and a launch pad to start a separate actual worker .exe - but then you turn into yet more permission problems: Vista may not want to launch that worker .exe because it's not in the proper location, and antiviral software may sound the red alert as you tinker with another "executable" file.

I would be inclined to limit the introduction of "kernel" upgrades to functional or even structural update releases of your application, and employ an installer application for those, while providing corrective update releases via online updates which require no new "kernel".

HTH,

Jan Schenkel.

[AndyP]

Another approach is to allow your install maker program to manage the updates.

I use this set up maker

http://www.ssesetup.com/

It's free for non-commercial use and has a built in update feature.