Delphi forms in dlls

Is it good idea to put Forms that have complete functionality in dll. And main app will invoke dll function that开发者_JAVA技巧 returns form object.

The accepted way to do this in Delphi is to use packages rather than DLLs.

Packages are essentially DLLs but with Delphi specific capabilities that allow VCL objects to be used across package boundaries.

Trying to do this with DLLs will lead to a variety of problems that packages deal with. One downside of packages is that all modules must be compiled with the same version of Delphi. But if you are wanting to share objects across module boundaries then you would face the same restriction if you used DLLs.

The Delphi documentation has extensive coverage of packages.

Having said all that, I would add that if you can put all your code into a single module (.exe or .dll) then it does make life a lot simpler.

Adding to the answers about using packages:

• Packages can only be used if both, the main app and all dlls (plugins) are written in Delphi and are written using the same version of Delphi
• DLLs can be written in any programming language that can create them and can be used by any program regardless of the programming language

So, using dlls rather than packages does make sense.

Regarding the actual question: Yes, it is possible to put forms into dlls and they usually work fine. Just make sure that you do not pass them around because they are only valid objects within the context of the dll. You will experience the odd problem with forms losing focus or coming up behind other forms. This can usually be fixed by passing a window handle from the main executable to the dll which is then used as the parent for the form.

Also note: TObject of your dll is different from TObject of your application. The same applies to other commonly used classes and variables like (Forms.)Application.

I have done it and it was a pain in the lower back but it was not impossible. The main program was written in Visual Basic 6, some modules were written in Delphi 6, others were written in Delphi 7 and Delphi 2007.

Conclusion: If you are sure you will never use something different than Delphi for your app and for your dlls (plugins) and are willing to always recompile everything when you switch Delphi versions, you should use packages. Otherwise it might be better to use regular dlls. (And are you sure you will always be the only person writing these dlls? Maybe at some time there will be a 3rd party developer for one of the dlls who does not own the Delphi version he needs.)

IMO this is sometimes a very good idea and the only way to go - for the reasons others have mentioned, I'm not a fan of packages, and am very comfortable with DLL's. I am currently adding functionality to an app written in Delphi 5 using Delphi XE - it was either use DLL's or write in D5 - of course I opted for the former: D5 app calls DLL's written in XE that contain all the latest and greatest features. (The first projects I did in Delphi were done via the old Borland Paradox - Paradox app invoked DLL's written in Delphi 1!)

But, I don't send the form or module from the DLL back to the main app - I just send the DLL module a structure containing what it needs to know to do its work, and when it's done and the DLL's form closes, it cleans up and then and returns a numerical code or structure back to caller indicating success, failure etc ( old fashioned but very effective).

Passing the form instance from the DLL back to your main app across the DLL threshhold can be problematic - note @dummzeuch's excellent answer above with some good tips on how to negotiate some of those problems should you decide that is your only solution.

+1 for everything that David Heffernan says.

Strategically, you really only need to implement forms (or other functionality) in external files if you're implementing a plug in system.

If you're going to allow plugins to be authored in any language, then DLL's are the only way to go.

If your plugin system will be restricted to developers with the same version of Delphi (same team perhaps?) then go with BPL's. The additional drawback of Delphi packages, from my perspective, is the need to deploy the VCL BPL's with your app, which are always more Mb than a single compiled module.

If on the other hand you want to write a modular system, you can still do that by implementing loose coupling & "plugin" techniques within your code and still compile to a single module.

If you put a form in a normal dll the form won't be able to intercept the TAB or arrow keys. I have been told that this is due to the OnKeyDown not be passed through.