Hi Doug, Thanks for pointing out that the GUI can have it's own DLL as well. I didn't really cover that as well as you mentioned. What you mentioned is a nice feature, i think,which may sometimes be over looked. The DLL can have it's own Form which opens a lot of possibilities. This makes for a number of opportunities more than just features as i explained.
Sounds like that your getting RTTI from the DLL to build the components, if i'm understanding. Very cool! Neil, a good book if you don't have is "Delphi Programming Problem Solver" by Neil Rubenking. You can find it on Amazon or EBay. It was written more for older versions of Delphi but still a good reference and has a nice DLL section if you should have an interest. Cheers, Charlie ----- Original Message ----- From: Doug Hale To: [email protected] Sent: Thursday, January 15, 2009 6:05 PM Subject: Re: [delphi-en] Problem with ShellExecute Great minds think alike.... LOL The DLL(s) can contain the GUI(s) I have completed two different projects along this line. In one, each DLL contains a feature. When the feature is selected, the DLL places its base panel on the EXEs form. The user then interacts with the DLL. This project belongs to a client so I don't have the code. The other one is an extensible simulator. Each component is a separate DLL and an implementation of the same abstract class. In this case, each DLL has it's own form. Each DLL exports a function that returns a class (class of) type. This a class type can be used to call the class constructor. The EXE creates a list of DLLs by looking in a directory. It builds an array of classes by loading each DLL and calling it's API to return the class. There are Class methods that return data about the class including a descriptive string to display for user selection. I own this code, so I can show it if there is interest. Doug Charlie Chambers 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] > > > ------------------------------------ > > ----------------------------------------------------- > Home page: http://groups.yahoo.com/group/delphi-en/ > To unsubscribe: [email protected]! Groups Links > > > > > ---------------------------------------------------------- > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.10.7/1895 - Release Date: 1/15/2009 7:46 AM > > ---------- ---------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.7/1895 - Release Date: 1/15/2009 7:46 AM [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
