TFRAME ONSHOW ONHIDE
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
-
13 avril 2010 à 22:40
cs_LePetitCurieux Messages postés 7 Date d'inscription jeudi 29 octobre 2009 Statut Membre Dernière intervention 23 novembre 2010 - 28 avril 2010 à 19:26
cs_LePetitCurieux Messages postés 7 Date d'inscription jeudi 29 octobre 2009 Statut Membre Dernière intervention 23 novembre 2010 - 28 avril 2010 à 19:26
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
https://codes-sources.commentcamarche.net/source/51610-tframe-onshow-onhide
28 avril 2010 à 19:26
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.
15 avril 2010 à 12:01
14 avril 2010 à 19:37
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.
14 avril 2010 à 11:56
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. ^^
13 avril 2010 à 22:40
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;