Normalement, les propriétés sont toutes à 0 donc False lors du InitInstance, lui je ne sais pas qui l'invoque, il me semblait que c'était implicite
Sans le inherited Create, il n'y a pas de chargement de la DFM, d'abord cela invoque InitializeNewForm, en XE3, cela force explicitement False pour Visible, il y a surement une raison à cela
Puis cela invoque InitInheritedComponent qui charge la DFM, Visible et les autres propriétés prennent ainsi leur valeur depuis celle défini dans l'Inspecteur d'objets
On peut voir aussi
property Visible write SetVisible default False;
devrait garantir un Visible à False, cette valeur n'est prise en compte que lorsque l'on charge une DFM qui ne mentionne pas la valeur (dans l'inspecteur, le gras indique le stockage, quand ce n'est pas en gras, cela utilise les valeurs de l'ancêtre ou celle par défaut)
En fait, ce n'est peut-être pas Visible qui pose problème mais Enabled
Enabled est resté à False suite au InitInstance
property Enabled: Boolean read GetEnabled write SetEnabled stored IsEnabledStored default True;
Idem, Enabled est hérité du TControl, sa valeur n'est pas stocké dans la DFM si on n'y touche pas, puisqu'à True par Défaut
Mais comme on ne charge pas la DFM, on n'utilise pas cette property default True donc Enabled reste à False
en code simplifié, le début du ShowModal c'est
1 2
| if Visible or not Enabled or MDI or déjà Modale then
erreur 'impossible de rendre modale une fenêtre visible' |
Ce qui est très mal fichu, le problème n'est pas visible mais "clickable" !
C'est un vilain amalgame par les développeurs de la VCL qui ont eu la flemme de gérer un message d'exception par critère d'exclusion lors d'un ShowModal
comme ceci en pseudo code
1 2 3 4 5 6 7 8
| if Visible then
erreur 'impossible de rendre modale une fenêtre visible'
if not Enabled then
erreur 'impossible de rendre modale une fenêtre désactivée'
if MDI then
erreur 'impossible de rendre modale une fenêtre enfant MDI'
if déjà Modale then
erreur 'impossible de rendre modale une fenêtre déjà affichée en modale' |
Par habitude, je mets systématiquement le inherited Create même si j'hérite directement d'un TObject, pour ce dernier comme le Create ne fait rien ce n'est pas perturbant, c'est un habitude à prendre pour éviter un jour ce genre de piège
Par contre le inherited Destroy dans un destructor est OBLIGATOIRE
effectivement je l'ai mise en commentaire car dans pas d'autre fenêtre dans le programme que je développe elle était en commentaire
Il ne faut pas confondre Create et OnCreate
dans le constructor, inherited doit être mentionné
dans le OnCreate, c'est un gestionnaire d'évènement, inherited n'aurai pas de sens, il ne doit pas être
Et c'est là qu'il y a peut être confusion, utilisé les deux en même temps, cela peut être trompeur,
Partager