What you intend to do is perfectly freezable and not very difficult. You'll be facing a number of problems, I'll enumerate some of them with a number of possible solutions, just to give you an idea. I've done something similar before, also I had no requirement to write modules in other programming languages. I used DLL's because of the smaller size (10 DLL's all statically linking the bits and pieces of VCL they need might be smaller then 10 tiny DCP's all dynamically linking to the packaged VCL, because you might end up distributing more bits and pieces of the VCL).
(1) What kind of services will be "shared" by the multiple modules? Only the main GUI or will there be more? My application had a module for downloading stuff from the Internet, and I had that as a "shared" module. (2) Will the different modules simply display a new page onto the tab-sheet or will the different modules be allowed more complex customizations (like registering a button on a global toolbar). Will the modules only register one page or will they be allowed to register multiple pages? If a single tab sheet per module is ok and the modules can't touch other parts of the GUI then you may use a much simpler communications between modules, based on simple DLL's. If the interaction is more complex you'll need to look towards things like Interfaces or "Handle" abstractions. Maybe set up some kind of message-based communication (think SendMessage) (3) Memory allocated in one module needs to be freed from that same module. You may use a DLL for allocating / freeing memory and use that from all modules. Delphi strings will be a problem (but Delphi strings are taboo any way if you need to be compatible with non-delphi DLL's - use PChar). (4) Are you ready to use plain "Windows" for communicating with windows generated from non-Delphi DLLs? You'll be doing some of that for sure - unless you turn your external modules into some kind of ActiveX, but that might generate more overhead for your distribution needs. (5) Are you sure you need such a complicated system? The Internet is getting faster by the minute, is it a problem to simply re-download an full "setup.exe" and use it to update an existing installation? That way you'll have a lot more control over the way things work, and a lot more options. -- Cosmin Prund > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Bowers, Michael P. ISD > Sent: 2 august 2007 18:11 > To: Borland's Delphi Discussion List > Subject: Dynamically loading TTabSheets into a TPageControl from > externalmodules? > > I am planning an application in Delphi 7 and for argument's sake, let's > say that it has a TPageControl in it. I would like each individual > TTabSheet to be dynamically loaded because we will be adding to the > application over time. The actual application I am writing right now > will just be a container for presentation and to give it presence in > the > system tray. > > For instance, one may be a status page, one may be a form to fill out > for help, a couple might be for admin access to some system, etc. Each > sheet is loaded as a different module (both form and executable code to > support it). We will be adding these sheets over time so I need to be > able to load these items dynamically and conditionally. Also, being > able to add these over time will mean that every time I need to add to > or change the application I don't need to redeploy the whole thing, the > application can pull in modules as they're added and put on an app > server or distribution share -- we have almost 15,000 machines now, and > project about 22,000 in a couple years, so deployment is always a > problem around here. > > I know that this can be accomplished with packages and they will share > a > TApplication object, but using packages assumes I'll be writing all > these items in the same language and compiler version so the RTTI will > match. In theory, I'd like to be able to use Delphi 2007 instead of > Delphi 7, or even VC++ or something else to load into the app. I might > not be the only one writing items for this, so I can't enforce a > development environment on other teams. > > So... what are my choices? Ideally I'd like to define a spec for .DLLs > so they can be written in any language, but is that even possible to > link them in in that way? Would it be clean, anyway? How can I handle > intercommunication between items using .DLLs? Or should I just stick > to > packages written under one version of Delphi? Perhaps there is a > solution using some sort of scripting component like Python4Delphi so I > can just drop in scripts? > > Has anybody done anything like this before? > > Thanks, > Mike > > ---- > Michael Bowers, Lead Client Management Analyst > Client Management, Desktop Solutions, Memorial Hermann Healthcare > System > Em: [EMAIL PROTECTED] > Ph: 713/448-6306 Failure is not an option. > It > Pg: 713/605-8989 x21934 comes bundled with Microsoft > products. > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
