Comment intégrer des applications multiples ?

J'ai une appli A et une appli B, toutes 2 Delphi (2005, Win32).

Sur une Form de l'appli A, je dois rajouter un bouton qui permettra d'accéder à une Form (je l'appelle Form F) de l'appli B. Lorsque je suis dans la Form F, je peux, bien sûr, accéder à toutes les Form de l'appli B...

Est-ce que cela signifie que je dois inclure dans l'appli A, l'ensemble des Forms et Fiches de l'appli B ?

Les 2 applis pèsent chacune 7Mo et, par la suite je devrai accéder de la même manière à 3, 4, 5 ou plus autres applis... A ce train là je vais donc me retrouver avec un unique programme de 100Mo.

J'ai l'impression que je me trompe quelque part...

Merci de votre réponse

Pour réduire la taille de ton exécutable, tu peux envisager d'utiliser les paquet d'exécution (fichier BPL). Mais cela t'oblige à déployer ces paquets avec tes applications, ce n'est pas toujours possible (contexte des utilisateurs, licence, pas de contrôle sur le déploiement...). Regardes la doc et juges.

Une autre solution consiste à fragmenter ton application en plusieurs DLL que tu charges selon les besoins (pas d'exemple à te donner).

cdlt

e-ric

Merci de ta réponse. C'est une bonne piste que tu me donnes là. Je n'ai jamais trop touché aux DLL et aux package et c'est donc l'occasion...

Je viens de lire la chose suivante (DELPHI 7 de Dahan & Toth) :

Citation:

---

Avec les packagess runtime, Delphi n'associe plus le code des composants à celui de l'EXE. Ce dernier devient donc plus petit(...) Comme l'éditeur de liens de Delphi est "intelligent", il supprime le code non appelé; de fait, un EXE avec les packages de runtime semblera plus petit mais l'ensemble des fichiers à fournir sera bien plus gros que l'EXE original sans package. En effet, le code n'étant pas inclus dans l'exec. final, le linker ne peut supprimer le code inutile(...) La possibilité de réduire le code est toute relative et ne s'apprécie que si vous devez fournir de nombreux EXE sur un site client (...)
Rares sont les situations réelles où cela représente un véritable avantage (les pb. de stockage sur disque dur n'existent plus, et la fourniture et le maintiend'1 ensemble cohérent de packages ont un coût qui est loin d'être négligeable)

---

Donc, comme le dit notre auteur, il faut peut-être relativiser...

A ce propos : un truc concernant la gestion de la mémoire que je n'ai pas compris. Dans mes applis, la grande majorité de mes fiches sont créées en utilisant :

Code:

---

1 2 3

if not Assigned(form1) then form1 := Tform.Create(self); form1.Show;

---

Si l'utilisateur ouvre l'ensemble des fiches, est-ce que cela signifie qu'elles se trouvent toutes en mémoire à un moment donné ? Ou alors que ça n'a rien à voir et que Windows se débrouille pour vider le code correspondant aux fiches inactives ? Clairement, comment fonctionne le "garbage collector" de Windows ? (si je déborde des limites de ce forum, excusez-moi...)

Salut je ne sais pas si c'est ce que tu cherches ou si j'ai bien compris ta question , mais mon appli marche un peu comme la tienne ( si j'ai bien compris :lol: )

En fait la mienne est une appli qui est decomposé en plusieurs dlls.
Chaque dll peuvent etres appelées par plusieurs applications differentes,
Et chaque dll peut appeller les Dlls de mon appli.

en fait j'ai crée une Unité commune a tout le monde qui a en charge de charger dynamiquement toutes les dll de mon appli .
Donc quand je lance une appli ou que je fais appel a une dll , ces derniere charge toute mes DLLs , qui me donne donc acces a tout le monde .

peut etre une solution pour toi ..

bye

Oui, c'est ça que je recherche. Tu as parfaitement compris :D
Je pense que c'est la meilleure solution.

Merci de ta réponse.

Salut

A ma connaissance, pas de garbage collector dans Windows et dans Delphi encore moins pour les objets comme les TForm. Mais ceci est à nuancer car si le propriétaire de la fiche n'est pas Nil mais un composant comme TApplication, la destruction de celui-ci entraînera la destruction de la fiche si ce n'est pas déjà fait.

Si c'est Nil, tu as intérêt à libérer explicitement ta fiche. Il est possible de détruire automatiquement une fiche à la fermeture de celle-ci via son événement OnClose (F1 pour les détails). Mais attention dans ce cas, les références à la fiche (Form1...) deviennent indéterminée et font rende le test Assigned() noin significatif d'où quelques agréables plantages en perspective.

cdlt

e-ric

Salut e-eric,

Ok. Effectivement, j'avais oublié le Release sur la Form qui permet de la libérer. Je n'ai jamais essayé.

Mais si le Assigned ne fonctionne plus dans ce cas, comment peut-on tester si la Form est créée ou non ?

Pardonne-moi d'insister... :oops:

Salut

Pour répondre directement avec une variable : bernique !
Free agit sur l'objet mais n'affecte pas la référence (la variable, c'est un pointeur amélioré).

Une idée consiste à utiliser FreeAndNil si tu contrôle la destruction, mais cela fait que tu n'utilise pas Release (on tourne un peu en rond).
Tu peux facilement bricoler un équivalent pour les fiches :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

uses Forms;   procedure ReleaseAndNil(var Obj); var Temp: TForm; begin Temp := TForm(Obj); Pointer(Obj) := nil; Temp.Release; end;

---

A tester bien sûr car il est évident que je ne l'ai pas fait (loin de moi ces contigences "techniques"). J'avoue que ce code (FreeAndNil) m'a toujours laissé preplexe et donné l'impression de ne pas avoir tout compris : La référence est affectée à Nil avant que l'objet soit libéré, y sont culottés ces Borland.

Alors attention aux p'tits rigolos qui emploie la variable FormXX déclarée automatiquement par Delphi dans le texte de leur classe de form, du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10

var Form1: TForm; ...   procedure TForm1.FormDestroy (Sender: TObject); begin ... Form1.Coucou := 'Je peux planter avec un plaisir inégalé'; end;

---

Rigolez pas (en 8 ans de Delphi, je l'ai vu un nombre incommensurable de fois, self a été défini pour les chiens!)

avec la routine plus haut ça peut faire Boum à l'exécution


Donc le mieux que tu as à faire reste de donner toujours un propriétaire en paramètre au constructeur.

cdlt

e-ric

Merci de la leçon :)
Je vais donc faire quelques expériences... et je passe en résolu.

A+