Quelles sont les différences entre un expert bpl delphi et un expert dll delphi

Question

Je travaille dans un expert Delphi IDE, maintenant pour éviter les problèmes de dépendances, je pensais reconstruire cet expert en tant qu'expert en DLL comme cela a été suggéré dans l'un de ceux-ci. réponses, maintenant mon expert (compilé en bpl) accède au Screen et Application variables globales (instances de l'IDE Delphi), donc je me demandais si je compile mon expert sous forme de DLL, je peux toujours accéder à ces variables et je veux aussi savoir which are the main differences between a bpl delphi expert and a dll delphi expert?

Answer 1

Dois-je compiler mon assistant sous forme de DLL ou de package ? Les packages sont plus faciles à charger et à décharger sans redémarrer l'IDE (et donc plus facile à déboguer), mais ils peuvent créer des conflits de dénomination d'unité dans l'IDE.Les conflits se produisent lorsque le nom d'une unité d'un sorcier correspond au nom d'une unité dans un autre package de conception chargé.Dans ce cas, les deux packages ne peuvent pas être chargés en même temps.La solution de contournement recommandée est de préfixer tous vos noms d'unité avec un préfixe "unique".GEXPERTS, par exemple, utilise "GX_" comme préfixe de nom pour ses unités.

Depuis ce très bonne source sur l'OTA :GExperts

Answer 2

Lorsque vous accédez à une variable globale, il s'agit de variables globales qui sont globales pour votre DLL, et non globales pour le BDS.exe principal.Je ne suis pas sûr, mais je pense que votre DLL aurait sa propre variable globale d'écran et d'application, si vous étiez liée dans Forms, et au cœur de la VCL.

Les éléments qui appartiennent à l'EDI lui-même sont accessibles via l'Open Tools Api (OTA).Je crois que de toute façon, vous ne partagez normalement aucun objet entre l'EDI et votre expert, et si vous essayiez de le faire, ce serait problématique.Tout ce que vous faites et qui contourne l'OTA sera vulnérable à des pannes étranges, en particulier dans les futures versions de l'EDI.

Les problèmes de dépendance sont bien sûr une raison majeure de ne pas utiliser de packages basés sur BPL, mais je pense qu'une raison encore plus importante est de maintenir une séparation complète entre les composants internes de votre outil et ceux de l'EDI.

N'oubliez pas qu'une cible DLL, comme une cible exécutable, est liée statiquement.C’est le cœur de la différence.Si votre expert fournit des fonctionnalités qui utilisent uniquement les interfaces OTA légales et publiques documentées, le passage à une DLL devrait se faire sans problème.Si vous utilisez des hacks de porte dérobée possibles avec les BPL, je ne peux pas vous conseiller davantage.