What are the differences between bpl delphi expert and dll delphi expert

I am working on an expert in the field of delphi IDE, now, to avoid dependency problems, I was thinking of rebuilding this expert as a dll expert, as suggested in one of these answers , now my expert (compiled as bpl) gets access to Screen global variables and Application (instances of the Delphi IDE), so I was wondering if I would compile my expert as a dll, I can still use these variables, and I also want to know which are the main differences between a bpl delphi expert and a dll delphi expert?

+4
source share
2 answers

Should I compile my wizard as a DLL or package? Packages are easier to load and unload without restarting the IDE (and therefore easier to debug), but they can create node naming conflicts in the IDE. Conflicts happen when the name of the wizard matches the name of the unit in another loaded design-time package. In this case, both packages cannot be downloaded at the same time. The recommended workaround is the prefix of all your items with a "unique" prefix. GExperts, for example, uses "GX_" as the name prefix for its units.

From this very good source about OTA: GExperts

+5
source

When you access a global variable, these will be global variables global for your DLL, not global for the main BDS.exe. I'm not sure, but I think your DLL will have its own global variable Screen and Application if you are connected in Forms and the VCL core.

Those things that belong to the IDE itself are available through Open Tools Api (OTA). I believe that you usually do not share any objects between the IDE by your expert, and if you tried to do this, it would be problematic. Anything you do bypassing the OTA will be vulnerable to weird paths, especially in future versions of the IDE.

Dependency problems, of course, are a big reason not to use BPL-based packages, but I think an even bigger reason is to maintain a complete separation between the internal components of the tool and the internal elements of the development environment.

Remember that a DLL target, such as an executable target, is statically linked. That is the essence of the difference. If your expert provides functionality that uses only legal, public, documented OTA interfaces, then the transition to the DLL should be no problem. If you use some of the back doors that are possible with BPL, then I cannot advise you further.

+1
source

All Articles