Tframe onshow onhide

Soyez le premier à donner votre avis sur cette source.

Snippet vu 6 944 fois - Téléchargée 19 fois

Contenu du snippet

Bonjour,

Après de pénible recherche, j'ai découvert comment obtenir un équivalent de OnShow / OnHide d'une TForm sur une TFrame.

Ce n'est pas intuitif donc j'en profite pour vous le partager.

Source / Exemple :


uses
  Forms, Dialogs, Classes, Controls, StdCtrls, Windows, Messages;

type
    
  MaFrame = class(TFrame)
  private
    _OnShow : TNotifyEvent;
    _OnHide : TNotifyEvent;
    
    procedure _SetOnShow(ponshow: TNotifyEvent);
    procedure _SetOnHide(ponhide: TNotifyEvent);
    
    procedure FrameOnShowHide(var M: TMessage); message CM_SHOWINGCHANGED;
  published
    property OnShow : TNotifyEvent write _SetOnShow;
    property OnHide : TNotifyEvent write _SetOnHide;
  end;

implementation

procedure MaFrame._SetOnShow(ponshow: TNotifyEvent);
begin
  _OnShow := ponshow;  
end;

procedure MaFrame._SetOnHide(ponhide: TNotifyEvent);
begin
  _OnHide := ponhide;  
end;

procedure MaFrame.FrameOnShowHide(var M: TMessage);
begin
  inherited;
  
  if Showing then // onShow
    if Assigned( _OnShow ) then
      _OnShow( Self )
  else // onHide
    if Assigned( _OnHide ) then
      _OnHide( Self );
end;

Conclusion :


Voila, c'est pas grand chose et ça peut être utile.

A voir également

Ajouter un commentaire

Commentaires

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
31
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
31
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;

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.