On Aug 18, 2006, at 4:34 AM, Steven Hedgepeth wrote:
I wanted to ask you to expand on your installation method, if you
don't mind.
No problem. I use my method because it works and it makes the
program simpler for the end-user. They only have one program to deal
with.
As some of you have pointed out, there are times when my method is
clearly not the best course of action. For example, on corporate
networks, where applications are shared off a server, any client,
regardless of rank (except the admin of the server) has read-only
permissions to the applications on the server. If you need to write
files to the application's folder on the server just to get it to
run, then a separate install program is most defiantly the best option.
If you need to install any system files, like dll's on Windows, I
would absolutely suggest an installer that hooks in with the system
and, more importantly, is a separate program. This also makes
uninstalling much easier.
However, personally, I really don't like to deal with shared system
libraries or external *required* files. I make everything I could
possibly need internal. Because of this, all the files that I could
ever want to install are completely proprietary, maintained by me,
are used exclusively by that one program, and are located in an area
with regular read/write access.
When one of my apps with a built-in installer launches, it runs my
installer thread. Here's the pseudo code for one of my apps that
requires the folders for preferences set up before the program runs...
App.Open
Launch a new instance of the installer thread
End Sub
InstallerThread.Run
// locations of files are hard coded
Create, if necessary, ~/Library/Preferences/Copyup/Logs/
Create, if necessary, ~/Library/Preferences/Copyup/Logs/0.txt
// that file ^ is embedded in the app when it's built - I just
use a textoutput stream to create the file
Create, if necessary, ~/Library/Preferences/Copyup/Schedules/
Create, if necessary, ~/Library/Preferences/Copyup/Schemes/
If there were no problems, then show the main window.
End Sub
And of course, the uninstaller works backwards. For that program,
there is a checkbox for deleting preferences files on quit on the
about window. When the app quits, if that checkbox is checked, the
uninstaller thread runs.
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>
