Discussion :

[Pedro]

Salut à tous

Toujours dans l'optique de faire un programme entièrement modulaire, j'ai choisi d'utiliser les packages pour m'affranchir des DLL et de tous les problèmes que ça engendre.
Seulement j'ai des soucis que je n'arrive pas du tout à identifier
Voila l'architecture du programme:

• Un exécutable
• Un package commun à tous qui contient des routines, classes et constantes. J'y suis obligé parce que malgré UnloadPackage, je ne peux pas utiliser le même unité dans différents packages (Sinon, c'est trop simple ). Ce package est "Seulement en exécution"
• Un package pour chaque plugin qui publie une classe qui a toujours le même nom pour tous les packages. Chacun de ces packages :
  
  • utilise le package commun.
  • Register et Unregister les classes dans les sections initialization et finalization
  • Contient au moins une TForm
  • Est "Seulement en exécution"
  
  

Seulement, dans l'exécutable, j'utilise des unités du package commun. Je les ajoute donc dans les uses.
Lors du chargement du programme, je charge le package avec LoadPackage, je récupère la classe puis récupère avec une de ces méthodes, les propriétés du plugin puis je décharge le package avec UnloadPackage.
Tout se passe bien.
J'essaie ensuite de lancer un des plugins, je (re)charge donc le package en question (OK) et je récupère la classe (OK) je lance sa méthode. Et là, Vlan! Acces Violation (donc pas OK)...
Donc pour tester, avant même de créer quoi que ce soit dans la méthode de la classe du package, j'ai mis un ShowMessage. Il n'apparait même pas! Ce n'est donc pas mon code qui est en cause...

J'ai d'ailleurs l'impression que LoadPackage et UnloadPackage ont de sérieux problèmes: Certaines choses comme les unités utilisées devraient être purgées mais elles ne le sont pas...

Bref, je me mélange un peu les pinceaux et je suis complètement perdu.
Si quelqu'un pouvait m'aider à mettre en place ce système, ce serait sympa
Que ne faut-il pas oublier? Quelles options de projet doivent être activées ou non? Est-ce que cette architecture vous parait correcte? Si un train part d'Orléans à 14h30 et qu'un autre part de Dunkerque à 18h26, quel est l'âge du capitaine?

Merci d'avance

[sjrd]

Tu n'aurais pas oublié de cocher la case "Construire avec les paquets d'exécution" dans les options du projet ?

Sans ça, impossible de jouer correctement avec les paquets.

[chaplin]

Justement, il veut éviter d'utiliser cette option pour ne pas avoir a gérer tous les packages necessaires au fonctionnement de l'exe. Je crois que c'est un mal nécessaire. La philosophie des package (.bpl) est de disposer d'une modularité du programme, mais forcément il faut s'appuyer sur des bibliothèques de fonctions utilisés par tous les packages, donc ces dernières doivent aussi être contenu dans les packages. En fait travailler avec des packages Delphi, comme la communication se fait au travers de classe et d'inferface, utiliser de cette manière, on peut parler de framework VCL au même titre que de framework .NET.
On peut pas gagner sur tous les plans.

[Kaféine]

Salut,

Lors du déchargement du package, il faut également désenregistrer les classes associées et libérer les forms du module instanciées.

Déchargement des forms du module instanciées dans l'application hôte

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
var
  I: integer;
begin
  with Application do
  begin
    for I := ComponentCount - 1 downto 0 do
    begin
      if FindClassHInstance(Components[I].ClassType) = LeHandleDuModule then
        Components[I].Free;
    end;
  end;

et libérer les classes du module enregistrées

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
    UnRegisterModuleClasses(LeHandleDuModule);

ensuite on libère le package

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
    UnloadPackage(LeHandleDuModule);

[Andnotor]

J'avais utilisé une technique similaire pour la configuration d'une machine outil. Chaque paquet représentait un élément de la machine en fonction des besoins du client (Type/nombre d'outils, type/nombre de porte-pièces, chargeur, outil de mesure, etc.). Et comme toi, un paquet avec les classes et routines de bases et N paquets chargés dynamiquement (un par élément machine).

Ce qui me dérange dans ton énoncé est:

Seulement, dans l'exécutable, j'utilise des unités du package commun. Je les ajoute donc dans les uses.
Lors du chargement du programme, je charge le package avec LoadPackage...

A la compilation, les unités seront incluses dans l'exe. Celles comprisent dans le paquet (chargé dynamiquement) ne peuvent pas être connues à ce moment là! Et utiliser les deux méthodes en même temps risque bien d'être générateur de problèmes !

Un package pour chaque plugin qui publie une classe qui a toujours le même nom pour tous les packages.

Ce qui veut dire que tu te limites à un plug-in à la fois. Dommage (mais je ne connais pas ton but)

Dans mon cas,

- Un paquet de base contenant une classe de base connue par l'exe et les paquets. Cette classe publiait uniquement le nécessaire pour son initialiser et quelques méthodes communes.
- N paquets avec des classes dérivées de la classe de base mais jamais avec le même nom !

[Pedro]

Merci pour toutes vos réponses !

Tu n'aurais pas oublié de cocher la case "Construire avec les paquets d'exécution" dans les options du projet ?

Sans ça, impossible de jouer correctement avec les paquets.

Oui De toutes façons, si je ne coche pas cette option, ça ne marche pas du tout

Justement, il veut éviter d'utiliser cette option pour ne pas avoir a gérer tous les packages necessaires au fonctionnement de l'exe. Je crois que c'est un mal nécessaire. La philosophie des package (.bpl) est de disposer d'une modularité du programme, mais forcément il faut s'appuyer sur des bibliothèques de fonctions utilisés par tous les packages, donc ces dernières doivent aussi être contenu dans les packages. En fait travailler avec des packages Delphi, comme la communication se fait au travers de classe et d'inferface, utiliser de cette manière, on peut parler de framework VCL au même titre que de framework .NET.
On peut pas gagner sur tous les plans.

Bah figure-toi que j'aimerais bien décocher cette option mais rien ne passe (i.e. aucune classe n'est trouvée alors que le package est correctement chargé) si elle n'est pas activée.

Salut,

Lors du déchargement du package, il faut également désenregistrer les classes associées et libérer les forms du module instanciées.

Déchargement des forms du module instanciées dans l'application hôte

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
var
  I: integer;
begin
  with Application do
  begin
    for I := ComponentCount - 1 downto 0 do
    begin
      if FindClassHInstance(Components[i].ClassType) = LeHandleDuModule then
        Components[i].Free;
    end;
  end;

et libérer les classes du module enregistrées

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
    UnRegisterModuleClasses(LeHandleDuModule);

ensuite on libère le package

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
    UnloadPackage(LeHandleDuModule);

OK j'avais déjà trouvé cette manip. Par contre, j'ai un TPersistent et non TComponent comme classe de base. Bon, je n'ai qu'à modifer juste la classe d'héritage
Par contre, je n'ai pas à détruire comme tu fais à la fin (OnDestroy) puisque lorsque le plugin est "lancé":

• Le package est chargé
• La classe est récupérée depuis ce package et créée (hérite de TPersistent)
• Avec les fonctions RTTI, je récupère la méthode qu'il me faut et je l'exécute.
• Une fois le traitement du plugin terminé, je détruis l'objet créé plus haut (FreeAndNil)
• Je fais UnRegisterModuleClasses et UnloadPackage.

A moins que Delphi ne me crée des trucs dans mon dos, je ne devrais pas avoir à faire comme tu fais

A la compilation, les unités seront incluses dans l'exe. Celles comprisent dans le paquet (chargé dynamiquement) ne peuvent pas être connues à ce moment là! Et utiliser les deux méthodes en même temps risque bien d'être générateur de problèmes !

Je sais! Et je pense d'ailleurs que le problème vient de là En revanche, si je veux ajouter le package à l'exe, il faut qu'il soit Run time et design time? Parce que sinon, niet!

Ce qui veut dire que tu te limites à un plug-in à la fois. Dommage (mais je ne connais pas ton but)

Ah mince Certains plugin en appellent d'autres... J'avais pas fait attention à cette éventualité

Dans mon cas,

- Un paquet de base contenant une classe de base connue par l'exe et les paquets. Cette classe publiait uniquement le nécessaire pour son initialiser et quelques méthodes communes.

Oui donc tu fais un package runtime ET designtime et tu l'installes pour pouvoir l'utiliser dans ton exe?

- N paquets avec des classes dérivées de la classe de base mais jamais avec le même nom !

A vrai dire, j'étais parti comme ça au départ. Mais comme je pensais (à tort) que chaque classe serait unique, j'ai utilisé le même nom. De quelle façon tu récupères le nom de la classe? Est-ce que le fait d'utiliser le même nom peut provoquer des problèmes?

[Andnotor]

Oui donc tu fais un package runtime ET designtime et tu l'installes pour pouvoir l'utiliser dans ton exe?

Non je n'avait qu'un paquet (aucun composant à installer). Le contenu est connu par l'intérmédiaire du fichier dcp (équivalent dcu pour les packages) et est ajouté à la liste des paquets d'exécution.

Pour les paquets dynamiques, il est inséré dans la liste des paquets requis.

Est-ce que le fait d'utiliser le même nom peut provoquer des problèmes?

Tu ne dois tout simplement pas pouvoir enregistrer deux fois la même classe.

Pour le reste, il faut que je resorte quelques backup et te redonnerai des nouvelles (Si je ne les ai pas encore classé verticalement )

Mais en gros je pense qu'au moment de l'enregistrement de la classe, je remplissait aussi une liste disponible dans le paquet de base, style TPlugInClassList.

[Pedro]

Non je n'avait qu'un paquet (aucun composant à installer). Le contenu est connu par l'intérmédiaire du fichier dcp (équivalent dcu pour les packages) et est ajouté à la liste des paquets d'exécution.

Oui mais de cette façon, impossible de compiler: toutes les ressources (constantes, routines, etc.) que j'y inclus sont indisponibles! C'est d'ailleurs pour cela que j'ajoute les unités concernées dans les uses de l'exécutable...

Pour les paquets dynamiques, il est inséré dans la liste des paquets requis.

Oui ça je pense que j'ai bon

Tu ne dois tout simplement pas pouvoir enregistrer deux fois la même classe.

Je pense que c'est même certain! Mais à part ça, est-ce que ça pose problème? Autrement dit: est-ce que mon problème viendrait de là?

Pour le reste, il faut que je resorte quelques backup et te redonnerai des nouvelles (Si je ne les ai pas encore classé verticalement )

Volontiers Mon projet est malheureusement au point mort tant que je n'ai pas résolu ce gros problème

Mais en gros je pense qu'au moment de l'enregistrement de la classe, je remplissait aussi une liste disponible dans le paquet de base, style TPlugInClassList.

Mmmhh... Encore un variante de cette méthode Mais dans mon cas, puisque les plugins sont chargés/déchargés à la volée et uniquement lorsqu'on en a besoin, je ne peux pas tenir une liste comme ça!

[Andnotor]

Lucky boy Du premier coup.

J'avais bien une liste de classes et l'enregistrement ce faisait comme suit:
(Je vais parler en PlugIn pour que tu comprennes bien.)

Première chose, une BPL est comme une DLL. Chaque PluginBPL exporte une procédure pour l'enregistrement. Elle attend un paramètre qui est une procédure CallBack dans l'exe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
procedure RegisterPlugInClasses(Proc :TRegisterProc);
exports RegisterPlugInClasses;

Deux avantages:
1. Si cette procédure n'est pas trouvée, ce n'est pas un PlugIn
2. Dans mon cas, certaines BPL pouvaient regrouper plusieurs PlugIns. (Proc sera appelé une fois par PlugIn)

Dans l'exe, une simple procédure pour retrouver toutes les BPL (FindFirst, FindNext) et un GetProcAddress.

Voilà en gros ce que cela donnait:

Paquet commun:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Type
  TRegisterProc = procedure(PlugInClass :TPlugInClass);

BPL PlugIn:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
procedure RegisterPlugInClasses(Proc :TRegisterProc);
begin
  //Enregistre le(s) PlugIn(s)
  Proc(TPlugIn1);
  //Proc(TPlugIn2);
end;
 
exports RegisterPlugInClasses;

Et dans l'EXE:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
var
  ClassList :TClassList;  //Dérive de TList, contient toutes les PlugInClass
 
procedure LoadPlugInLibraries;
var
  SearchRec :TSearchRec;
  Found, i :integer;
  Path :string;
  //Prcocédure appelée depuis la BPL (Paramètre Proc)
  procedure DoRegisterPlugInClass(PlugInClass:TPlugInClass);
  begin
    Classes.RegisterClass(PlugInClass);
    classList.Add(PlugInClass);
  end;
  //Recherche la procédure exportée et l'appelle
  procedure RegisterLibrary;
  var
    BPL :THandle;
    RegPlugInProc :procedure(Proc :TRegisterProc);
  begin
    BPL := LoadLibrary(PChar(Path +SearchRec.Name));
    if BPL <> 0 then
    begin
      @RegPlugInProc := GetProcAddress(BPL, 'RegisterPlugInClasses');
 
      if @RegPlugInProc <> nil
      then RegPlugInProc(@DoRegisterPlugInClass)
      else FreeLibrary(BPL);
    end;
  end;
begin
  classList := TClassList.Create;
  Path := X:PlugInPath\; //Chemin des PlugIns
 
  //Recherche tout les paquets
  Found := FindFirst(Path +'*.bpl', faAnyFile, SearchRec);
  while Found = 0 do
  begin
    RegisterLibrary;
    Found := FindNext(SearchRec);
  end;
end;

Tu me diras que finalement les PlugIns pourraient n'être que des DLL et non des BPL . Oui en effet ! Mais l'avantage ici est qu'un nouveau PlugIn pourrait facilement dériver d'un autre en liant simplement l'ancienne BPL

Ensuite la procédure exportée ne renvoi que la classe et c'est l'exe qui se charge de l'enregistrer et des éventuelles manipulations. La gestion est ainsi centralisée.

[Pedro]

Merci! Ah c'est pas mal comme système ça
Je vais essayer de le tester!
Si il y a d'autres idées, je suis preneur!

[Andnotor]

Oui mais de cette façon, impossible de compiler: toutes les ressources (constantes, routines, etc.) que j'y inclus sont indisponibles! C'est d'ailleurs pour cela que j'ajoute les unités concernées dans les uses de l'exécutable...

Tu dois les mettre dans les uses . La seul différences entre compiler avec et sans paquets et que l'information est lue soit depuis le dcp, soit le dcu. Même combat!
Ce que je disais était par le LoadPackage.

Mmmhh... Encore un variante de cette méthode Mais dans mon cas, puisque les plugins sont chargés/déchargés à la volée et uniquement lorsqu'on en a besoin, je ne peux pas tenir une liste comme ça!

De nouveau, je ne connais pas le but de ton application .
Dans mon cas, je devais tout connaitre. En fonction des choix de l'utilisateur je devais lui passer des sous classes pour de nouveaux choix jusqu'à une classe finale. (Le tout implémenté principalement par procédures de classe et InheritsFrom)

A toi de gérer une liste de BPL (ie. Base des registres) et tu supprimes simplement la boucle (FindFirst, FindNext)

[Pedro]

Tu dois les mettre dans les uses . La seul différences entre compiler avec et sans paquets et que l'information est lue soit depuis le dcp, soit le dcu. Même combat!
Ce que je disais était par le LoadPackage.

OK

De nouveau, je ne connais pas le but de ton application .

Ah désolé
En fait, ce sujet recoupe un peu mon autre sujet ici:
http://www.developpez.net/forums/d68...orm-interface/
Voici comment fonctionne l'application:
L'exécutable en lui même ne sert qu'à ouvrir, enregistrer des fichiers et lancer des plugins.
Ces fichiers contiennent des informations (observations topographiques) et chaque plugin effectue divers traitement dessus (saisie, import, calculs, etc.)
J'ai une classe qui regroupe toutes les données pour chaque fichier ouvert. Il suffit donc que je passe cette classe au plugin (ainsi que d'autres paramètres) pour effectuer le traitement.
Chacun de ces plugins affiche une TForm et fait ses propres traitements qui sont radicalement différents les uns des autres.
J'ai donc un package pour chaque plugin, un package commun (classes, routines, constantes) et un autre package qui contiendra les routines d'édition/création de données que j'utilise un peu partout.

Dans chaque package de plugin, je publie donc une classe qui:

• Permet de récupérer les infos du plugin (Caption, Hint, Icone, etc...)
• Lancer le plugin proprement dit: afficher la TForm
• Le cas échéant, insérer un Frame dans la fiche des paramètres du programme si le plugin a des options paramétrables

Comme je le disais plus haut, au démarrage du programme, il parcourt le répertoire des plugins et charge les infos de tout ce qu'il trouve (en chargeant et déchargeant le package à chaque fois). Je maintiens une liste des plugins disponibles (nom du package, icone, etc.).
Lorsqu'un plugin est lancé, je recharge le package récupère la classe, la crée, lance sa méthode ad-hoc, détruit la classe puis libère le package.
Et c'est là que j'ai mon AV...

Voila où j'en suis

[GoustiFruit]

J'ai ce lien dans mes signets, est-ce que ça aide ?
http://pluginmgr.dennislandi.com/

[Pedro]

J'ai ce lien dans mes signets, est-ce que ça aide ?
http://pluginmgr.dennislandi.com/

Merci

Je l'ai rapidement survolé et le sujet n'est pas tout à fait le même que le mien. Mais il peut y avoir des idées qui pourraient m'inspirer pour mon problème.

[Pedro]

Salut

Bon j'ai fait un mix entre mon ancienne méthode des DLL et le système de Callback de Andnotor (merci à lui ).
En utilisant des class of TMachin, ça marche très bien... Sauf que j'ai à nouveau cette foutue fuite de mémoire qui m'avait décider de tenter de changer ma méthode de plugins

Je suis obligé d'utiliser SimpleShareMem malgré les Callback sinon, pas de chocolat (j'ai des strings dans des classes passées en paramètre). Et dès que j'affiche une TForm, j'ai une fuite de mémoire minuscule mais quand même. Cette fuite s'agrandit à chaque affichage de la form du plugin.

Si j'utilise ShareMem, la routine que j'utilise (ReportMemoryLeaksOnShutdown) ne détecte plus rien même si je fais volontairement une création de pointeur/objet sans destruction...

Je vais donc continuer avec cette méthode pour au moins finir le programme. Et j'essaierai de trouver un autre système plus tard...

Je clos le sujet mais si quelqu'un a un remède miracle, je suis preneur!
Merci à tous

[Andnotor]

Juste une indication supplémentaire.

Mes paquets ne faisaient strictement rien si ce n'est déclarer les classes.
Toute la gestion (ex. création d'objets) se faisait depuis l'exe (J'aime bien centraliser )

Ainsi je n'avais aucun besoin de partage de mémoire ni de recompiler tous les PlugIns à chaque changement de virgule .

[Pedro]

Juste une indication supplémentaire.

Mes paquets ne faisaient strictement rien si ce n'est déclarer les classes.
Toute la gestion (ex. création d'objets) se faisait depuis l'exe (J'aime bien centraliser )

Les miens ne déclarent pas des classes mais la création/exécution se fait aussi dans l'exe : c'est le callback qui crée la classe passée en paramètre.
Ca simplifie énormément le code

Ainsi je n'avais aucun besoin de partage de mémoire ni de recompiler tous les PlugIns à chaque changement de virgule .

Oui mais j'ai laissé tomber les packages vu le nombre de problèmes que j'avais avec
C'est vrai que ma méthode est loin d'être la meilleure mais en tout cas, elle fonctionne
Je ne comprends d'ailleurs toujours pas pourquoi j'ai eu tous ces problèmes avec les packages.
Chaque tuto que j'ai lu montrait en quelques lignes quelque chose qui fonctionnait visiblement impeccablement. Ce n'était jamais le cas chez moi
Je veux bien que cette méthode soit la meilleure et je suis prêt à étudier plus profondément le probléme mais si je dois passer 106.000 ans à faire en sorte juste qu'elle fonctionne, je préfère revenir à mes premières méthodes et ces bonnes vieilles DLL De plus, aucun tuto ne convient vraiment à ma méthode. A croire que je suis le seul qui veuille faire des plugins avec des TForm dedans