inline versus object dans les dfm

Bonjour,

J'ai créé plusieurs frames que j'ai recensé dans ma palette de composants en mettant les unités correspondantes dans des paquets et en implémentant la procedure Register.

Ces frames sont réutilisables dans plusieurs fiches...

Voilà mon problème, parfois après avoir modifié une fiche utilisant une de ces frames je me rend compte que les composants internes à la frame deviennent accessibles via le concepteur de fiche, alors qu'initialement ce n'est pas le cas (la frame est vu comme un seul composant). Je m'explique : Dans le fichier dfm de ma fiche, Delphi remplace le mot clé "object" par "inline" pour déclarer ma frame, du coup celle-ci déclare tous ses sous-objets, et ceux-ci deviennent donc manipulables dans le concepteur.

Hors j'ai remarqué que lorsque mes frames sont déclarées en inline à l'exécution je me trouve confronté à des bugs incompréhensibles (violations d'accès aléatoires, composants en double, etc...).
Qu'est-ce qui fait que Delphi déclare un composant en inline et non en object dans un fichier dfm ? Comment l'éviter ?

Merci d'avance.

Personne ne sait comment est geré ce mécanisme de inline "vs" object dans les fichiers dfm de Delphi ?

Euh non, j'avoue que c'est un mystère pour moi aussi :?

Citation:

---

Envoyé par ZZZzzz2

Personne ne sait comment est geré ce mécanisme de inline "vs" object dans les fichiers dfm de Delphi ?

---

je pense qu'inline permet justement ce mode de gestion particulier des TFrame qui sont effectivement modifiables une fois posées dans une fiche.

Je pense également qu'il ne faut pas utiliser TFrame pour gérer un composant dans la palette, à priori un TWinControl voir un TCustomPanel serait plus adapté car ils n'ont pas de notion de DFM.

Salut,

Justement, j'ai essayé de me frotter aux subtilités de la gestion des dfm dans Delphi. Je n'ai pas tout compris, et je dois dire que la doc que j'ai trouvée sur le web est plus que succinte, mais j'ai quand même compris un truc ou deux.

Depuis l'IDE, tu peux créer des Frames et des Form, et les éditer avec l'éditeur de fiche habituel.

Au sein d'un même projet, tu peux ré-utiliser les frames et les forms que tu as créés dans d'autres unités de ton projet - je travaille sous bds2006, mais je crois que c'est la même chose sous les autres versions : les forms et les frames apparaissent dans la catégorie "Eléments héritables" de la palette d'outils, les frames peuvent aussi être collés comme des composants normaux (ou presque) depuis l'item "Frames" de la catégorie "Standard" de la palette d'outils de l'éditeur de fiches (ouf!).

Pour cette manip, tu n'as pas besoin de compiler tes composants et de créer un package de conception : en fait, l'IDE retrouve ses petits à l'aide du .dpr - le source de ton projet ("Projet>Voir le source" mon IDE est dans les choux je n'ai plus l'intitulé exact ). Dans ce dpr, il y a l'ensemble des unités que tu as ajoutées à ton projet, et certaines unités sont annotées avec un petit commentaire :
" Form1 in "src\Form1.pas" {Form1},
Frame42 in "src\Frame42" {Frame2: TFrame},
...
"
Ces commentaires ne sont pas juste des commentaires, c'est en fait à partir de ces tags que l'IDE te propose les classes héritables et les frames que tu peux coller. La syntaxe (que j'ai pu constater, mais je ne suis pas sûr d'avoir testé tous les cas de figure) est la suivante :
{Toto} veut dire que l'unité déclare une TForm, de type TToto, décrite dans un dfm,
{Toto: TFrame} veut dire que l'unité déclare une TFrame, de type TToto, décrite dans un dfm.

Rien de très nouveau là : tu as sûrement déjà constaté cela en regardant un dpr.

Mais quand je dis que l'IDE retrouve ses petits à l'aide de ces tags, je veux dire la chose suivante :
- j'ai retiré le commentaire "{Form1}" du .dpr :
le projet compilait toujours, avec le même résultat;
par contre, lorsque j'ouvrais une unité qui contenait une fiche TForm2 dérivant de TForm1, l'IDE m'affichait un message d'erreur disant en gros "Erreur à la création de la fiche Form2" et je ne pouvais plus éditer la fiche,
- j'ai transformé le commentaire "{Frame42: TFrame}" en "{Frame42}" :
aucun changement à la compilation ni à l'exécution;
je pouvais toujours éditer des fiches contenant des Frame42 comme si de rien n'était, il y a juste que "Frame42" n'était plus proposé dans la liste des Frames à coller dans un dfm.

Le fait que la compilation et l'exécution fonctionnent pareil veut bien dire cela : ces commentaires, présents dans le dfm, servent juste à l'IDE, pour savoir quels sont les composants non compilés disponibles.

Côté syntaxe du dfm : lorsque tu colles dans une fiche une Frame ou une Form, la déclaration dans le dfm n'est pas :

Code:

---

1 2 3 4 5 6

object MaForm : TMaForm ... object FrameAccueil : TFrame42 ... end end

---

elle utilise ce fameux mot réservé "inline":

Code:

---

1 2 3 4 5 6

object MaForm : TMaForm ... inline FrameAccueil : TFrame42 ... end end

---

et dans ce cas, je peux éditer tous les éléments de ma FrameAccueil depuis la fiche de ma Form - les modifications sont alors indiquées dans le dfm.

Voilà le fruit de mes investigations de fourmi :) J'ai été un peu long, mais j'espère avoir été précis.


Dans ton cas : est-ce que l'unité qui décrit ton composant -celle que tu as mis dans un package- est aussi présente explicitement dans le .dpr de ton projet? est-ce que sa déclaration est accompagnée d'un "{MaForm}" ou "{MaFrame: TFrame}"?
Si c'est le cas, je pense que tu peux :
-soit trouver un moyen de ne pas avoir à déclarer l'unité dans le dpr du projet : si elle fait partie d'un package, le composant doit être déclaré dans l'interface du package,
-soit, si tu as besoin de code présent dans ton unité, vire le commentaire "{Blabla}" - l'IDE ne considèrera plus ton composant comme un truc connu dont elle peut bidouiller le dfm avec une déclaration "inline"

LeGEC>

J'y vois un peu plus clair, merci pour tes explications.
En fait ma frame était directement déclaré dans mon projet et là j'avais ces fameux problèmes de "inline" qui revenaient aléatoirement. Désormais j'ai déplacé ces frames dans un paquet et je n'ai plus de problèmes donc ton explication avec le DPR semble coller. Bizarrement cependant j'ai tantôt ce problème également avec un composant dans une fiche qui lui est bien placé dans un paquet à part alors là je n'explique pas pourquoi.

Une remarque cependant : j'ai remarqué que dans mon fichier DPR j'ai des lignes "FrmNewBidule in 'F_FrmNewBidule.pas' {FrmNewBidule: TFrame },"

Alors qu'il ne s'agit pas d'une frame mais d'une fiche ?? Alors si j'essaie d'insérer un nouveau cadre dans ma fiche il me propose effectivement le nom de cette fiche comme cadre mais au moment de l'insérer m'affiche une erreur de type "Impossible d'insérer une fiche...." donc encore une fois cela vérifie ton hypothèse. Du coup j'ai viré ces ': TFrame' erronés..
Sauras-tu me dire par contre pourquoi certains modèles apparaissent en noir et d'autres en rouge dans la liste des cadres possibles ?

Citation:

---

Envoyé par ZZZzzz2

LeGEC>

J'y vois un peu plus clair, merci pour tes explications.

---

Heureux que ça ait pu servir :)

Citation:

---

Envoyé par ZZZzzz2

Sauras-tu me dire par contre pourquoi certains modèles apparaissent en noir et d'autres en rouge dans la liste des cadres possibles ?

---

Arf... ça non.
Un rapide test : les items deviennent rouge ou noir selon que certaines unités correspondantes sont ouvertes ou non dans l'éditeur. J'ai aussi eu des cas où l'IDE refusait de me montrer un dfm en mode texte parce que la frame correspondante était utilisée dans un autre dfm, en cours d'édition.
Ca pourrait être une histoire de frame en cache ou pas? ou alors de fichier .dfm locké par Delphi ou pas?

Je n'ai pas mieux pour l'instant.

Merci :-)) !

Citation:

---

Envoyé par LeGEC

Heureux que ça ait pu servir :)



Arf... ça non.
Un rapide test : les items deviennent rouge ou noir selon que certaines unités correspondantes sont ouvertes ou non dans l'éditeur. J'ai aussi eu des cas où l'IDE refusait de me montrer un dfm en mode texte parce que la frame correspondante était utilisée dans un autre dfm, en cours d'édition.
Ca pourrait être une histoire de frame en cache ou pas? ou alors de fichier .dfm locké par Delphi ou pas?

Je n'ai pas mieux pour l'instant.

---