Quote:
>Need r help,
>how can i auto update an application the way Real Audio does ?
That's a question that's way too broad to answer in any detail; but I
can at least give a few suggestions.
There are basically three parts to this problem: "How can I find out
whether there are updated files available?", "How can I retrieve those
updated files?", and "How can I install the files once I've retrieved them?"
For "How can I find out whether there are updated files available?":
Well, one good approach is to use the WinInet support built into MFC. Use
the CInternetConnection class to set up a connection to the Internet, and
CHttpConnection or CFtpConnection to connect to your web server or FTP server.
You can retrieve a web page, or an FTP file, that your app can parse to
determine what update files are currently available:
For "How can I retrieve those updated files?": Well, as long as you've
got that CInternetConnection running, use it. :) Again, you can use a
CFtpConnection to connect to your FTP server, and download the update files
from there.
For "How can I install those files once I've retrieved them?": Well,
this is where things get just a little bit interesting. :) The fundamental
problem here is that you'll be wanting to replace files belonging to your
own application; but, since your application is running at the time, it may
well have those files open, preventing you from replacing them. (This
particularly goes for the applications' .EXE file itself.) The usual
approach to this problem is to write a very small "file mover" application.
When your main application finishes downloading the updated files into a
temporary directory somewhere, it launches the file-mover application, sends
it the instructions for what files should be copied where, and quits. The
file-mover application receives its instructions, waits for the main
application to quit (thus closing all its open files), moves the updated
files to their final locations, and relaunches the main app, which then tells
the file-mover to quit.
One thing to watch out for at this stage: You may need to update files
that are still open even after your app quits. For example, if a new service
pack for
Visual C++ comes out, you may well want to switch to the new
MFC DLL
files that go with it; and if there are any other MFC apps running on the
system, your filemover application still won't be able to install the new
DLLs correctly, since they'll still be held open by the other application.
So your filemover application will need to check the results of its
file-moving calls, watching out for ERROR_ACCESS_DENIED and other errors that
would mean that the file is open. For these open files, the filemover should
schedule the files to be moved at the next reboot; the details for doing this
are different on Win95/98 and on WinNT--check the MoveFileEx documentation
for more details. Once it's done this, it should _not_ relaunch the main
app; instead, it should display the traditional "You must restart Windows to
complete this update; do you want to restart Windows now?" dialog, and call
ExitWindowsEx() if the user gives permission.
--
\o\ If you're interested in books and stories with transformation themes, \o\
/o/ please have a look at <URL:http://www.halcyon.com/phaedrus>. Thanks! /o/
\o\ FC1.21:FC(W/C)p6arw A- C->++ D>++ H+ M>+ P R T++++ W** Z+ Sm RLCT \o\
/o/ a cmn++++$ d e++ f+++ h- i++wf p-- sm# /o/