Thats the exact opposite of how I thought about it, thanks for the mind-openner!
Best regards Neal Campbell Abroham Neal Software Programming Services for Windows, OS X and Linux (540) 242 0911 --------------------------------------------------------------------- Try Spot for OS X, the intelligent DXCluster Client at www.abrohamnealsoftware.com - $15.99 On Thu, Jan 15, 2009 at 4:09 PM, Charlie Chambers <[email protected]> wrote: > Hi Neal, > What you need to remember is that the main unit code is to cover the needs > of the GUI of the main form and the DLL will take care of areas you wish to > update for the future. I'd put the update code in the main form code unit > and load the DLL as part of the activation of the main unit. When you wish > to download a new update, i'd unload DLL, download then reload the new DLL. > Having said this, this is precisely where the term "DLL Hell" came from. It > might be good to have code to revert to a previous dll just in case to cover > all bases or at least, put a DLL version function into the DLL. > > Looks like Doug beat me to this! <g> > > Cheers, > Charlie > > ----- Original Message ----- > From: Neal Campbell > To: [email protected] > Sent: Thursday, January 15, 2009 1:14 PM > Subject: Re: [delphi-en] Problem with ShellExecute > > Hi Charlie > > Please excuse my newness to the list and Delphi programming (I am > returning after 10+ years). In the DLL example, how would that work? > The main program will call the functions in the DLL to determine if a > new release is available and downloads it, while quitting the main > program? How does the DLL stay alive when you kill the main program so > that you can delete/init it with the new version? > > I need to do this myself and am learning from this email chain tremendously? > > Why hasn't someone created a small framework for this like we have for > OS X (Sparkle)? > > Thanks > Neal Campbell > Abroham Neal Software > > On Thu, Jan 15, 2009 at 12:33 PM, Charlie Chambers > <[email protected]> wrote: >> Hi Bobby, >> Another idea is to put the update functions/procedures into a DLL >> and just update the DLL as opposed to the full exe. >> >> Cheers, >> Charlie >> >> ----- Original Message ----- >> From: Bobby Clarke >> To: [email protected] >> Sent: Thursday, January 15, 2009 8:09 AM >> Subject: [delphi-en] Problem with ShellExecute >> >> I wanted to provide a web update facility for my program B.exe and >> decided that the easiest way was to write a small control program, >> A.exe, which checked the web for updates to program B.exe and then >> starts, via ShellExecute, the latest version of B, perhaps B009.exe. >> >> This all works very well. The problem comes when I try to update the >> control program A.exe. Clearly the new version must be called A.exe so >> that all the shortcuts work. I can download A.new and the only task now >> is to delete A.exe and rename A.new to A.exe. I have written a small >> console program C.exe that does this. The problem is knowing how to >> start C.exe. If I start with a ShellExecute from A.exe, the file A.exe >> seems to be locked even after A has finished and even if C.exe waits for >> two minutes before trying to change the A filenames. The A filenames >> themselves are not locked as I can change using Windows Explorer during >> the 2 minute wait. I can even change the names by hand-starting a >> different occurrence of C.exe. Starting C from B fails as the A file is >> still locked. >> >> I could place C.exe to be run on the next re-boot, but this seems messy >> and interferes with the user's control of his PC. Is there another >> option? All suggestions welcome. How do others update programs using the >> web? >> >> Bobby Clarke >> >> [Non-text portions of this message have been removed] >> >> [Non-text portions of this message have been removed] >> >> > > [Non-text portions of this message have been removed] > >
