I'm not sure what other people think about this, but I usually prefer
to place my installing code in the application that is being
installed, and not have a separate installer.
Sounds a bit crazy at first, but it makes the whole thing a lot
simpler for the user, and it makes creating the download files a lot
easier for the developer.
Basically, suppose you have a list of files that need to be placed in
various locations in order for your application to run. When my
programs start, the first thing they do is check to make sure that
those files exist. If they don't, then I write them out there myself
right then and there, right from my application. That way, I get
error checking and installing done all at once. Then, of course, I
provide an easy method of uninstalling the files. This is where my
approach has it's problems, unfortunately. I can see where a
standard system installer is a good idea (and about my previous post
about Mac users liking drag-and-drop installs, that's true, but OSX
does have a very cool installer program, also). Especially on
Windows, a correct uninstall requires that resources in use by other
applications are NOT removed. This is a bit hard to do if your
installer is built into your application and is totally proprietary
and not linked to the system in any way.
As for me, well, RB does such a fine job at making applications self
contained that I have never needed external shared libraries to be
installed. Because of this, my method works just fine for me. All
the files that I have ever needed to "install" for said program are
completely proprietary and are used exclusively by said program.
As for the programming, generally, the App.Open event launches a
thread that handles all startup routines. The thread usually
executes in a blink of an eye, unless a hard drive needs to get fired
up, so there's no need for a status bar. If any install is required,
however, I ask the user if they want my program to start writing
stuff to their hard drive, and if they click yes, I do it and then
show the main window as a signal of completion. Basically, if the
program runs, then the install is complete. Any file that I could
need to write to the hard drive is stored inside the application by
means of dragging whatever resource I need onto the project pane of
the project. From there, it is accessible from within your
executable as a string. To write it to the hard drive, use a
textoutputstream for text files, or a binarystream for binary files,
and just tell which ever stream to write what you're trying to
write. The data type of the data property of the Write method of
both the TextOutputStream and BinaryStream is a string.
And yes, I put the uninstall option in the menus somewhere. On OSX,
I put it in the application menu.
By the way, MAC is short for MAC Address, and Mac is short for
Macintosh. Just thought you'd want to know...
Andrew Keller
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
