Les fiches

Voici quelques-unes des principales méthodes des fiches

SetBounds(aleft, atop, awidth, aheight)

Une grande partie du code source d'une application est écrite pour répondre à des événements.

La liste des événements d'une fiche apparaît dans le volet événement de la fenêtre de l'inspecteur d'objets. Si le nom saisi ne correspond à aucune méthode existante, le gestionnaire d'événement est automatiquement créé : son entête est ajouté à la liste des méthodes de la classe TForm et un squelette de définition est inséré dans la partie implémentation de l'unité.

Attention : si une procédure événement est déclarée sans qu'aucune ligne de code particulière n'y figure, Delphi en supprimera toute trace lors de la prochaine sauvegarde du fichier.

Rien n'empêche d'utiliser un même gestionnaire d'événement pour plusieurs événements, c'est-à-dire, d'utiliser une même méthode pour traiter des événements d'origines différentes. Il est donc possible de définir une méthode générique applicable à n'importe quel composant. Il est également possible d'utiliser un même gestionnaire d'événement pour traiter des événements de natures différentes, associés à des composants également différents. Il suffit d'utiliser un gestionnaire d'événement correspondant à un type procédural identique ou compatible. Ainsi les événements distincts OnClick et OnDblClick appartiennent au même type TNotifyEvent. C'est pourquoi on peut affecter à ces propriétés une même procédure, répondant au modèle suivant :

Composant.UneMethode(Sender : TObject);

Lorsque l'on opère de cette façon, il devient nécessaire de pouvoir déterminer le composant exact qui a généré l'événement. C'est le paramètre Sender de la méthode événement qui permet cela puisqu'il s'agit d'un héritier d'une classe TObject. Il contient les informations nécessaires pour l'identifier. On utilise notamment les méthodes ClassType et ClassName pour connaitre le type et le nom de la classe du composant concerné par l'événement.

Exemple :

var
      f : TForm;
      b : TButton ;
    begin
      (* teste si l'objet reçu est une fiche *)
      if Sender.ClassType = TFrom1 then
      begin
        f := Sender as TForm;
        (* pratiquement équivalent au transtypage f := TForm1(Sender) *)
      end;

      (* teste si l'objet reçu est un bouton*) 
      if Sender.ClassType = TButton then
      begin
        b:=TButton(Sender);
        b.Caption:='Click';
      end;
    end;

I-C-1. Les événements associés à la souris▲

TMouseEvent = Procedure(Sender : TObject ; Button : TMouseButton ; Shift : TShiftState ; X , Y : Integer) of object;

TMouseButton = ( mbRight, mbLeft , mbCenter);

TShiftState = set of (ssShift, ssAlt, ssCtrl, ssLeft, ssRight, ssMiddle, ssDouble);

TMouseMoveEvent = procedure(Sender : TObject; TShift : TShiftState; X, Y : Integer) of objet;

procedure Tfsouris.FormMouseEvent(Sender:TObject ; Shift : TShiftState ; X,Y : Integer);
    begin
      caption:=IntToStr(X) + ' : ' + IntToStr(Y);
    end;

I-C-2. Les événements clavier▲

TKeyEvent = procedure(Sender : TObject ; var key : Word ; Shift : TShiftState) of object;

procedure paffichetouches(f : TfClavier; const MesUpDown : string ; var key : word)
begin
case key of
VK_LBUTTON : writeln('bouton gauche de la souris');
...
else
writeln(chr(key));
end;
f.setFocus;
end;

procedure TfClavier.FormKeyDown(Sender : TObject ; var key : Word ; Shift : TShiftState);
begin
paffichetouches(self,'(down)',key);
end;

procedure TfClavier.FormKeyUp(Sender : TObject ; var key : Word ; Shift : TShiftState);
begin
paffichetouches(self,'(up)',key);
end;

TKeyPressEvent = procedure(Sender : Tobject ; var Key : Char ) of Object ;

procedure TForm1.FormKeyPress(Sender : TObject ; var Key : Char);
begin
key:=UpCase(Key);
end;

La fermeture de la fenêtre s'effectue soit interactivement par l'utilisation du menu système ou par Alt+F4 soit au niveau de la programmation par la méthode Close. Cette action est associée à la génération d'un événement OnClose, de type TCloseEvent. Ce type est défini de la façon suivante :

TCloseEvent=procedure(Sender : TObject; var Action : TCloseAction) of object;

Action fait appel au type TCloseAction acceptant les valeurs prédéfinies suivantes :

• caFree : la fiche est détruite et la mémoire affectée est libérée ;
• caHide : la fiche n'est pas détruite, mais simplement cachée (Visible=False) ;
• caMinimize : la fiche n'est pas fermée, mais simplement réduite en icône : c'est l'action par défaut des fenêtres enfants MDI ;
• caNone : la fiche ne peut pas être fermée et rien ne se produit.

L'interception de l'événement OnClose est utile pour placer des demandes de confirmation.

La demande de fermeture d'une fiche

Proche de l'événement OnClose, l'événement OnCloseQuery est lié à la survenue d'une demande de fermeture de la fiche par l'utilisateur ou le programme.

OnCloseQuery appartient au type TCloseQueryEvent défini de la façon suivante :

TCloseQueryEvent = procedure(Sender : TObject; var CanClose : Boolean) of object;

C'est par la valeur affectée à l'argument booléen CanClose qu'est indiquée l'autorisation ou l'interdiction de fermeture de la fenêtre. Lors d'une demande de fermeture, l'événement OnClose est exécuté et elle exécute elle-même la méthode CloseQuery pour savoir si la fenêtre peut être fermée. Cette méthode est une fonction retournant un booléen. Lorsque la valeur True est retournée, l'événement OnCloseQuery est généré, permettant au programmeur d'intervenir sur le déroulement de la fermeture en donnant une valeur à CanClose. Si l'autorisation de fermeture est donnée, Close tente de fermer la fiche en générant un événement OnClose. À nouveau le processus peut être interrompu ou détourné par l'indication d'une valeur à l'argument Action.

Les objets Application et les fiches possèdent chacun des événements OnActivate et OnDeactivate, générés respectivement lorsqu'un composant devient actif ou inactif.

I-E-1. Le focus▲

I-E-2. L'ordre de tabulation▲

I-E-3. Les propriétés associées au focus▲

I-E-4. Les méthodes associées au focus▲

Canfocus : Boolean;

Du point de vue de la conception, les deux types de fiches (MDI mère et fille, appelées également MDI parent et MDI enfant) se distinguent par leur propriété FormStyle, dont le type est défini par une énumération des quatre valeurs suivante :

• fsMDIChild fenêtre MDI fille ;
• fsMDIForm fenêtre MDI mère ;
• fsNormal fenêtre non MDI ;
• fsStayOnTop le fenêtre reste toujours en avant-plan.

La fiche MDI mère doit être la fiche principale de l'application et est par conséquent unique. Par ailleurs, il est recommandé de ne pas déclarer les fiches filles dans la liste des fiches autocréées de la boite de dialogue Option de Projet (volet fiche), mais dans la liste des fiches disponibles, c'est-à-dire dont la création incombe au programmeur.

Les fiches MDI filles sont conçues indépendamment de la fiche mère, mais elles apparaissent lors de l'exécution toujours à l'intérieur de la fiche MDI et ne pourront jamais sortir de son cadre lors de l'exécution du programme. On ne peut créer qu'une seule fiche MDI mère par application, mais il peut exister plusieurs types différents de fiches MDI filles contenues dans une même fiche mère.

La démarche consiste à définir un modèle de fenêtre enfant, et de créer dynamiquement une ou plusieurs instances de cette fiche au cours de l'exécution du programme.

La détection de la fenêtre enfant active en cours d'exécution s'effectue à l'aide de la propriété ActiveMDIChild qui contient une référence de fiche.

Par exemple pour synchroniser le libellé de la barre de titre de la fiche mère avec celui de la fiche active :

Caption:=ActiveMDIChild.Caption

Le nombre de fiches enfants actuellement présentes dans la fiche parent est indiqué dans la propriété MDIChildCount, de type integer. Cette valeur correspond au nombre d'éléments du tableau MDIChildren qui contient les références de toutes les fenêtres enfants de l'application.

MDIChildren[I:integer] : TForm;

La valeur d'index utilisable dans ce tableau peut varier de 0 à MDIChildCount-1.

Exemple : réduction de toutes les fenêtres filles de l'application

for i := MDIChildCount - 1 downto 0 do MDIChildren[i].WindowState := wsMinimized;

Il existe plusieurs solutions pour faire apparaître des menus spécifiques à un document enfant, lorsqu'il devient actif, dans la barre des menus de la fiche MDI parent.

On peut créer tous les menus nécessaires dans la fiche mère et rendre certains menus visibles ou invisibles selon la présence ou non d'au moins une fiche fille Cela convient plus particulièrement quand il n'existe qu'un seul modèle de fiche fille. Par exemple, pour ne faire apparaître l'option édition de la barre principale de menu, appelée ici mnuEdition, que lorsqu'au moins une fenêtre MDI fille est présente dans l'application, utilisez l'instruction suivante :

mnuEdition.visible:=MDIChildCount > 0;

La deuxième solution consiste à créer les menus spécifiques dans les fiches et à fusionner les menus des fiches mère et filles lors de l'ouverture de la fille. La technique de la fusion des menus s'appuie sur les propriétés AutoMerge et GroupIndex des options menus.

Enfin, on peut également définir plusieurs menus principaux, avec des options adaptées à chacun des modèles de fiche enfant, et associer un menu à la fiche selon le contexte en valorisant différemment la propriété Menu par programmation, selon le principe suivant :

if MDIChildCount > 0 then menu:=mnu1 else menu:=mn2;

Les applications MDI possèdent souvent la liste des fenêtres filles ouvertes dans l'un des menus, généralement le menu fichier ou fenêtre. Pour obtenir cette gestion de liste automatiquement dans une application MDI Delphi, déclarez l'une des options de menu de la barre principale des menus dans la propriété WindowMenu. À l'exécution du programme, la liste des documents ouverts apparaît automatiquement au-dessous du dernier élément de l'option de menu indiqué. La fenêtre MDI fille active (c'est-à-dire la fiche ActiveMDIChild) apparaît dans la liste avec une marque de sélection.

Attention : il ne peut y avoir qu'une seule liste des documents MDI par barre de menus.

La liste des documents ouverts s'accompagne généralement d'un ensemble de commandes permettant la réorganisation de ces fenêtres. Les applications MDI doivent en effet inclure des options de menu contenant les commandes Mosaique, Cascade et Réorganiser les icônes afin que les utilisateurs puissent modifier la disposition de leurs documents ouverts dans la zone client de la fenêtre cadre.

La méthode Tile réorganise l'ensemble des documents de telle manière que chacun d'eux possède la même taille et que l'ensemble des fenêtres MDI filles occupe la totalité de la zone client de la fenêtre MDI mère. Tile ne s'utilise que dans la fenêtre MDI mère, et ne reçoit aucun argument. La disposition exacte des documents dépend en fait de la valeur de la propriété TileMode, suivant les valeurs :

• tbHorizontal : chacune des fiches occupe la totalité de la largeur de la zone client de la fiche MDI mère ;
• tbVertical : chacune des fiches occupe la totalité de la hauteur de la zone client de la fiche MDI mère.

Attention : la définition de la propriété TileMode n'a de sens que pour une fiche MDI parent.

Si vous souhaitez modifier le comportement par défaut de Tile, insérez une instruction modifiant la valeur de TileMode

TileMode:=tbVertical;
Tile;

La méthode Cascade dispose les fenêtres MDI filles de telle sorte qu'elles se recouvrent partiellement, le haut de chacun des documents restant visible afin de pouvoir le sélectionner.

Attention : la méthode Cascade, comme Tile, ne s'applique que pour la fenêtre MDI mère.

La méthode ArrangeIcons appartient au même groupe que Tile ou Cascade, mais n'agit que sur les documents réduits en icône en réorganisant leur présentation en bas à gauche de la zone client de la fenêtre MDI mère. Exemple :

ArrangeIcons;

Les méthodes Next et Previous permettent d'activer respectivement la fiche MDI fille suivante et le fiche MDI fille précédente, par rapport à la séquence de l'ensemble des documents ouverts.