Discussion :

[Pedro]

Salut

Je remonte le sujet parce que je pense avoir trouvé une solution plus élégante dans le livre de Paul Toth et Olivier Dahan
La solution est expliquée dans le chapitre VI-22 La gestion des packages.

Pour info, voici comment ça se présente:
On utilise les packages qui publient une classe héritant d'une classe mère.
Cette classe est donc chargée et c'est elle qui s'occupe de créer et afficher la fiche incluse dans le package. De cette façon, je peux utiliser n'importe quelle fiche! Simple et efficace!

Mais (il y en a toujours un) je me heurte à un souci de taille que j'ai systématiquement eu lorsque j'essaye cette méthode.
Si je ne coche pas "Construire avec les paquets d'exécution", GetClass et FindClass ne trouvent jamais la classe dans le package.
Si je coche cette option en y mettant le strict minimum dont mon package, soit "vclx;vcl;Package1" (oui c'est un package de test ), ça marche sans problème, mais je perds complètement l'intérêt d'avoir des plugins dynamiques puisqu'il me faut connaitre le nom du package avant la compilation
J'ai beau lire et relire ce chapitre ainsi que quelques tutos glanés ça ou là, je ne trouve aucune mention de ce problème...

Ai-je oublié quelque chose??

Merci d'avance

PS: j'utilise D2009

[Franck SORIANO]

Essaie en utilisant LoadPackage :
- Tu compiles ton projet avec les paquets d'exécutions "vclx;vcl" (encore que tu peux peut-être t'en passer, je ne sais pas).
- Tu compiles les packages de tes plugins séparément et tu les places dans un répertoire "plugin" par exemple.
- Au démarrage de l'application, tu scannes le répertoire plugin et tu appelles LoadPackage pour chaque package que tu trouves. LoadPackage appellera les Initialization des unités du package, ce qui permettra d'y faire quelques RegisterClass...
- Ensuite, tu devrais pouvoir utiliser FindClass.

[Pedro]

Merci pour ta réponse Franck

Essaie en utilisant LoadPackage :
- Tu compiles ton projet avec les paquets d'exécutions "vclx;vcl" (encore que tu peux peut-être t'en passer, je ne sais pas).
- Tu compiles les packages de tes plugins séparément et tu les places dans un répertoire "plugin" par exemple.
- Au démarrage de l'application, tu scannes le répertoire plugin et tu appelles LoadPackage pour chaque package que tu trouves. LoadPackage appellera les Initialization des unités du package, ce qui permettra d'y faire quelques RegisterClass...
- Ensuite, tu devrais pouvoir utiliser FindClass.

C'est exactement et intégralement ce que je fais
La seule différence est que j'ajoute mon package dans la liste... Et que le répertoire s'appelle PluginS
Ceci dit, ça m'embête quand même de devoir cocher cette option (je vais devoir distribuer les paquets avec l'application et j'utilise pas mal de composants tiers )
Je vais quand même essayer sans mettre mon package dans la liste...
Il n'y a aucun moyen de le faire sans cocher cette option? Une quelconque option du projet à activer/désactiver ?

[Pedro]

Effectivement, ça marche sans mettre le package dans la liste Merci pour l'info!
Par contre, toujours la même question: N'y a-t-il aucun moyen de faire cela sans cocher cette option ? Comment la rendre package-aware (Si j'ose m'exprimer ainsi ) ?

[Pedro]

Par contre, toujours la même question: N'y a-t-il aucun moyen de faire cela sans cocher cette option ? Comment la rendre package-aware (Si j'ose m'exprimer ainsi ) ?

Un autre problème s'est posé lorsque j'étais en train de développer cette méthode.
Je ne peux pas utiliser la même unité dans chaque paquet. Or, j'ai 3 unités que j'utilise assez souvent: une pour les constantes, une pour les routines et une pour les classes. Je les utilise un peu partout. Ces unités sont intégrées dans le projet de l'exécutable.
Mais si je charge un paquet qui en contient une, je le décharge et je charge un autre paquet qui la contient aussi, j'ai une erreur comme quoi l'unité est déjà déclarée... Alors que le premier paquet est déchargé!
Donc comment faire:

• Avec plusieurs fichiers .inc et des combinaisons de Define?
• Copier les fichiers concernés avant la compilation dans un autre nom?
• Une option de projet à cocher/décocher que je ne connais pas?

Bref, cette approche est peut-être plus Delphi-friendly mais c'est pas la panacée non plus

[LeGEC]

Hmmm... je ne suis pas expert en gestion des paquets, je tente quand même.

Tu peux dire qu'un paquet A a besoin d'un autre paquet B.

Je te suggèrerais donc de créer un nouveau paquet, du style "CommonPackage", et de dire que les paquets qui contiennent tes composants ont tous besoin de ce CommonPackage.

J'ose espérer que Delphi gère correctement la dépendance des paquets et charge/décharge ceux qu'il faut au bon moment.

[Pedro]

Merci pour ta réponse

Tu peux dire qu'un paquet A a besoin d'un autre paquet B.

Je te suggèrerais donc de créer un nouveau paquet, du style "CommonPackage", et de dire que les paquets qui contiennent tes composants ont tous besoin de ce CommonPackage.

Je suis en effet parti sur cette méthode. En revanche, on dirait que tout se téléscope: J'utilise des routines/classes/constantes du paquet commun en ajoutant les unités aux uses. Et j'ai des erreurs assez bizarres qu'il ne devrait pas y avoir. Des AV en l'occurence...

J'ose espérer que Delphi gère correctement la dépendance des paquets et charge/décharge ceux qu'il faut au bon moment.

Bah visiblement non: il ne décharge pas les références aux unités chargées...