TFRAME ONSHOW ONHIDE

Signaler
Messages postés
4202
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
13 juin 2020
-
Messages postés
7
Date d'inscription
jeudi 29 octobre 2009
Statut
Membre
Dernière intervention
23 novembre 2010
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/51610-tframe-onshow-onhide

Messages postés
7
Date d'inscription
jeudi 29 octobre 2009
Statut
Membre
Dernière intervention
23 novembre 2010

Bonjour,
Pour redtux:
D'abord et avant tout merci pour ce petit source.
Par contre juste une petite remarque, pourquoi ne pas avoir mis un exemple concret de son utilité ?
En effet brut de forme ce source à mon avis n'en démontre en rien de son utilité, sauf pour des personnes utilisant ou confrontées aux problèmes des Tframes.

Pour f0xi:
Tu met en avant la syntaxique de l'ecriture de redtux ??? En faisant référence à la norme syntaxique de Borland ???
Perso, Borland enfin le garçon qui a remis le pascal en poupe, l'a fait à l'epoque du CPM. Sur sa lancée il a porté son ambition sur x86 et d'ailleur, precurseur, il a mis en avant le premier language accessible orienté POO sous cet environnement (pour info a l'epoque on parlait des Elvis et bien sur de la gestion des évènements tout cela en 80x25 caractères en MSDOS). A l'époque un objet enfant on devait le nommer elXXXXX.
Donc tout cela pour te dire que.......
Le underscore _ est une bonne façon de notifier par son prefixe le lecteur de code de la portée de la variable, aussi bien et même mieux quel que soit le language employé.
En effet la plupart des languages et surtout cross compilateurs presents sur les plateformes krossoft sont à orientation .NET. La casse de caractère devient alors importante. Entre ftoto et Ftoto nous ne parlons pas en fait de la même chose....
Pour tout dire, j'ouvre un débat sur le fond.
Sur la forme :
Ce source est il presenté comme un objet ou une astuce ???
Pquoi mettre en published certaines propriétés ???
Dans le code modif de Foxi, pquoi surcharger le TFrame , quel est son utilité ???
Juste des questions non pas pour moi, mais pour les autres :)

Tout cela mérite débat pour quelques lignes de code.
Dsl d'etre peut etre hors sujet mais bon... Au moin je participe.
Dans l'attente des reps, Bonne prog.
Messages postés
12
Date d'inscription
lundi 29 novembre 2004
Statut
Membre
Dernière intervention
14 avril 2010

Merci pour ses compléments d'informations. J'enregistre le tout ^^
Messages postés
4202
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
13 juin 2020
33
parce que le code est copié de TCustomForm ... d'ou le dynamic restant.

pour les conventions, on respecte celle de Borland ... sinon tout le monde fait n'importe quoi et personne ne comprend plus rien.

"f" pour les variables privées
"p" pour les pointeurs
"set" et "get" pour les fonctions de propriétés

"_" et "__" s'utilise plutot pour les déclarations d'implémentation privée (variables, constantes et objets globaux).

voilou ...

bon code.
Messages postés
12
Date d'inscription
lundi 29 novembre 2004
Statut
Membre
Dernière intervention
14 avril 2010

Bonne idée de rajouter les procédures DoShow et DoHide, merci pour ton commentaire.

Par contre, une simple question : pourquoi rendre ses procédures "dynamic" ? La surcharge de ces méthodes dans une classe fille ne serait d'aucun intérêt vue que leurs comportements est entièrement délégués aux évènements.

Sinon, au sujet de la nomenclature, chacun ses habitudes. Que ce soit fOnShow ou _OnShow, étant donné que le langage pascal autorise les deux, cela ne pose aucun problème. En ADA ce serait différent, je te l'accord, mais en pascal ce n'est pas bien grave. ^^
Messages postés
4202
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
13 juin 2020
33
ouch un peu sur les conventions de code :

type
TFrame = class(Forms.TFrame)
private
fOnShow : TNotifyEvent;
fOnHide : TNotifyEvent;
procedure CMShowingChanged(var M: TMessage); message CM_SHOWINGCHANGED;
protected
procedure DoHide; dynamic;
procedure DoShow; dynamic;
published
property OnShow : TNotifyEvent read fOnShow write fOnShow;
property OnHide : TNotifyEvent read fOnHide write fOnHide;
end;

{ TFrame }

procedure TFrame.CMShowingChanged(var M: TMessage);
begin
if Showing then
DoShow
else
DoHide;
end;

procedure TFrame.DoHide;
begin
if Assigned(fOnHide) then
fOnHide(Self);
end;

procedure TFrame.DoShow;
begin
if Assigned(fOnShow) then
fOnShow(Self);
end;