Remarques de développement avec C++ Builder 5

Partie III - par Gilles Louise

46. La classe TEdit

L'objet TEdit vous permet entre autres de dialoguer avec l'utilisateur. Par exemple, vous pouvez l'inviter par ce petit objet d'entrez une chaîne de caractères. Dans ce cas on intercepte la chaîne saisie après que l'utilisateur a appuyé sur la touche Entrée (code ASCII 13). Par exemple, sélectionnez l'objet Edit, il se trouve dans l'onglet standard de la palette de composants (petit logo montrant les deux lettres "ab"). Positionnez-le sur la fiche principale Form1. Dans l'inspecteur d'objets, sélectionnez "événements" et cliquez sur "OnKeyPress", C++ Builder vous crée la méthode correspondante. Saisissez la ligne suivante :

void __fastcall TForm1::Edit1KeyPress(TObject *Sender, char &Key)
{
if(Key==13) Application->MessageBox(Edit1->Text.c_str(),"OK",MB_OK);
}

Cette instruction signifie que quand l'utilisateur a appuyé sur "Entrée", on affiche le contenu de l'objet Edit dans un MessageBox. Vous remarquez qu'on entre dans cette méthode avec en main la variable Key qui est précisément le code ASCII de la touche appuyée par l'utilisateur. Tant que cette touche n'est pas Entrée (code ASCII 13), on ne fait rien, on sort immédiatement de la méthode. Notez que si vous voulez connaître les codes ASCII des touches du clavier, il vous suffit de les afficher, par exemple :

void __fastcall TForm1::Edit1KeyPress(TObject *Sender, char &Key)
{
Application->MessageBox(IntToStr(Key).c_str(),"OK",MB_OK);
}

On affiche ici le code ASCII de la touche appuyée dans un MessageBox à chaque fois qu'une touche est appuyée.

Remarquez le flag MB_OK qu'on utilise souvent à titre d'exemple dans nos MessageBox. C'est le plus courant, mais il y en a bien d'autres : MB_ABORTRETRYIGNORE, MB_OKCANCEL, MB_RETRYCANCEL, MB_YESNO, MB_YESNOCANCEL, etc. Positionnez le curseur sur le mot MessageBox et faites F1 (aide en ligne) pour plus d'informations.

Il est très souvent utile de n'accepter dans un TEdit qu'une certaine catégorie de caractères. Par exemple, si le TEdit représente un nombre entier, il faudra n'accepter que les chiffres (codes ascii compris entre 48 et 57). Pour une meilleure utilisation, on accepte aussi toujours la touche "back space" (code ascii \b) qui permet d'effacer le dernier caractère. Donc, dans le gestionnaire d'événement OnKeyPress, on annulera le caractère envoyé si ce n'est ni un chiffre ni la touche d'effacement (touche qui se trouve au-dessus de la touche Entrée et qui représente une flèche vers la gauche).

void __fastcall TForm1::Edit1KeyPress(TObject *Sender, char &Key)
{
if((Key<48||Key>57)&&Key!='\b') Key=NULL;
}

Vous voyez que la variable Key est envoyée comme référence (grâce à l'opérateur & qui exprime que la variable Key est envoyée non pas en tant que valeur mais en tant qu'adresse, cela revient à dire que son contenu est comme renvoyé au programme appelant dans le cas où Key serait modifiée à l'intérieur de la méthode). Cela permet à l'utilisateur de contredire l'événement puisque si Key (c'est-à-dire la touche appuyée) n'est ni un chiffre ni la touche d'effacement alors Key est annulée (Key=NULL;), ce qui a pour effet d'ignorer complètement la touche appuyée par l'utilisateur. Ainsi, si l'utilisateur appuie sur une lettre, celle-ci ne sera pas affichée. On s'assure ainsi qu'il n'y aura que des chiffres dans le TEdit. Notez la propriété MaxLength qui permet d'exprimer le nombre de caractères maximum qui seront acceptés dans le TEdit. Notez aussi que pour une valeur entière, on évitera d'afficher un zéro non significatif au début du TEdit. Ceci se programmera à l'événement OnChange.

void __fastcall TForm1::Edit1Change(TObject *Sender)
{
int n;
if((n=Edit1->Text.Length())!=0)
if(Edit1->Text[1]==48)
Edit1->Text=Edit1->Text.SubString(2,n-1);
}

On teste d'abord la longueur du Tedit et on en profite pour mettre cette longueur dans l'entier n. Si cet entier est non nul, on teste le premier caractère du Tedit c'est-à-dire le premier caractère de l'AnsiString Edit1->Text (n'oubliez pas que l'indice des AnsiString commence à 1). Si donc ce premier caractère est égal à 48 c'est-à-dire le code ascii du caractère zéro (if(Edit1->Text[1]==48)), on supprime ce caractère en chargeant dans Edit1->Text son propre contenu à partir du deuxième caractère sur une longueur de n-1, ce qui a pour effet de supprimer le premier caractère si celui-ci est zéro.

47. La classe TList

C'est une liste de pointeurs. On la déclare par l'opérateur new :

TL étant ainsi une instance de type TList, si P est un pointeur de type char*, on ajoutera le pointeur P à la liste en écrivant :

Les pointeurs de TList étant du type void* c'est-à-dire finalement que ce sont des pointeurs indéterminés, il faut donc convertir ce pointeur en char* dans notre cas ce pourquoi il faut écrire char* entre parenthèses pour effectuer une conversion de void* en char*. Si vous voulez déclarez une zone mémoire via malloc et ajouter un pointeur vers cette zone, on écrira par exemple :

Le ième pointeur de la liste est donné par l'expression TL->Items[i], si ce pointeur est un pointeur de type char*, le jème caractère de ce pointeur sera donné par l'expression ((char*)TL->Items[i])[j] où l'on écrit clairement que TL->Items[i] est du type char*. Pour supprimer le ième pointeur de la liste, on écrira simplement ;

Voici un petit exemple complet. On déclare la constante bloc à 1000 pour un premier malloc. On déclare NbBlocs à 40. On déclare ensuite TL du type Tlist et on déclare 10 zones mémoire via malloc de bloc/2 octets et à chaque fois on ajoute le pointeur à la liste. On a donc une liste de 10 pointeurs chacun pointant une zone de bloc/2 octets. Ensuite, On va réallouer la mémoire pour chacun de ces pointeurs mais on va le faire en ajoutant à chaque fois un pointeur à la liste. On a donc après cette boucle 20 pointeurs, les pointeurs de 0 à 9 contiennent maintenant les anciennes adresses devenues inutiles et les pointeurs de 10 à 19 les nouvelles suite au realloc. On supprime alors les 10 premières adresses en supprimant dix fois le pointeur d'indice 0. Au bout de 10 fois, on n'a plus que les pointeurs d'indice 0 à 9 qui sont les pointeurs nouveaux suite au realloc. On fait cette réallocation NbBlocs fois en allouant à chaque fois un bloc de plus c'est-à-dire (j+1)*bloc, et ce pour éprouver les realloc et vérifier le bon fonctionnement de tous les pointeurs. Au bout du compte, on a 10 pointeurs sur 10 zones de NbBlocs*bloc octets. On remplit toutes ces zones, le fait de pouvoir y accéder est la preuve que c'est parfaitement correct. Ensuite on libère la mémoire de ces dix pointeurs et on efface l'objet TL. Copiez-collez ce code entre les parenthèses {} du tout premier constructeur TForm1 en entrant dans C++Builder et faites F9 pour exécuter, vous constatez que ça marche parfaitement car si l'accès n'était pas autorisé, on aurait eu nécessairement un accès violation, ce qui n'est pas le cas ici.

48. Conditions sur points d'arrêt

On donne un point d'arrêt via la touche F5, la ligne pointée par le curseur devient rouge, le programme s'arrêtera à cet endroit au moment de l'exécution et vous pourrez vous lancer dans un pas à pas (notamment via la touche F8, voir menu "Exécuter" pour plus d'informations). Maintenant, En cliquant sur le bouton droit de la souris pointant une ligne marqué "point d'arrêt" (ligne rouge), vous obtenez un menu déroulant qui vous donne la possibilité d'affiner ce point d'arrêt, c'est l'option "Propriétés du point d'arrêt". En choisissant cette option, une fenêtre apparaît et vous indiquez une condition d'arrêt. Si cette condition est réalisée, l'exécution s'arrêtera et vous aurez la main pour poursuivre en pas à pas. Par exemple, si vous voulez arrêter l'exécution si une certaine variable D=2, vous écrirez dans le formulaire présenté : D==2. Il faut juste se souvenir que s'il y a plusieurs conditions, elles doivent être isolées par des parenthèses par exemple (D1==2)&(D2==3).

49. Série de touches fréquentes

Pour accéder à vos fichiers réguliers, utilisez les touches du clavier. Ainsi, si vous travaillez toujours sur le même projet (ce qui est le cas de projets de longue haleine), vous l'ouvrez par Alt+F+R+0 (Alt active le menu général, F pour fichier, R pour réouvrir et 0 pour le dernier projet ouvert). Si vous avez plusieurs fichiers cpp à ouvrir, faites Alt+V+G, là cliquez "+" et choisissez le cpp voulu (Alt pour activer le menu, V pour Voir, G pour gestionnaire). Ou encore Alt+V+U qui appelle les unités, c'est d'ailleurs peut-être un meilleur choix puisqu'on peut par ce moyen charger plusieurs fichiers en même temps en indiquant un premier fichier puis un second tout en appuyant sur la touche MAJ ce qui provoque la sélection de toute la zone.

50. Les menus variables

Pour créer des menus variables, vous avez grosso modo deux possibilités : soit vous prédéclarez vos options à l'avance et à la main à la conception de votre application, soit vous créez ces options par programme. Si vous connaissez à l'avance le maximum d'emplacements à allouer durant l'exécution, la première solution est alors préférable. C'est le cas par exemple quand vous proposez à l'utilisateur les plus récents fichiers à réouvrir, vous les rajoutez dans le menu "Fichier" qui est en général la première option du menu principal d'une application, vous décidez par exemple de proposer les dix fichiers les plus récents.

Dans ce cas, vous prédéclarez ces options dans votre menu en sélectionnant dans votre fiche Form1 le menu principal, vous cliquez sur le bouton droit de la souris, vous choisissez "concepteur de menus". Là le concepteur de menu s'affiche et sélectionne pour vous la première option "Fichier", celle précisément où l'on va rajouter des options. Cliquez la case la plus en bas pour la sélectionner, rajoutez un séparateur (dans Caption saisissez le signe moins, c'est le code pour créer une fausse option qui servira de ligne séparatrice dans votre menu) puis sélectionnez à nouveau la dernière case et saisissez n'importe quoi dans Caption par exemple la lettre a puis recommencez l'opération par exemple dix fois pour réserver dix options en proposant à Caption les lettres de a à j. En réalité, ce qu'on entre dans Caption n'a aucune importance puisque cela sera renseigné par programme, c'est simplement une astuce pour réserver l'espace mémoire associé à ces options. On a donc un menu "Fichier" avec les options classiques puis à un moment donné une ligne séparatrice suivie de dix options qui contiendront jusqu'à dix noms de fichiers les plus récemment utilisés. Ici je conseille un petit truc, c'est d'initialiser le tag de la première option à 1, celle que nous avons déclarée avec Caption=lettre a. Les tags sont initialisés à 0 à chaque création d'option de menu, il suffit de mettre à 1 celui-là. Cela va nous servir dans le programme à repérer la première option destinée à recevoir des noms de fichiers récents. Si on ne prend pas cette petite précaution, il faudrait alors mémoriser l'indice de la première option variable (sachant qu'on part de 0 c'est-à-dire que Fichier1->Items[0] est la première option du menu Fichier que C++Builder a nommé Fichier1). Mais de ce fait, il faudrait modifier le source si par la suite vous insérez une option au menu Fichier avant ces noms car tous les indices se décalent d'une unité. En utilisant le tag de la première option des noms de fichiers récents et en l'initialisant à 1, on ne changera rien même s'il vous insérez des options dans votre menu. Cherchons dans ces conditions le numéro d'options correspondant à la première option variable :

où ok est un booléen et Prem un entier. Après exécution de ce code, Prem contient l'indice de la première option variable du menu repéré par le fait que son tag est à 1, Fichier1->Items[Prem] est donc cette première option.

Ensuite, à l'initialisation, il faut rendre invisibles toutes les options et donc inaccessibles d'où :

où MaxFic est le nombre maximum de fichiers autorisés à venir s'afficher dans le menu variable. Prem étant le premier indice, Prem+MaxFic-1 sera le dernier, pour tous ces indices le champ Visible sera mis à false, ce qui désactive l'espace entier réservé à ces noms de fichiers.

Imaginons maintenant que dans une TStringList, vous ayez les paramètres utilisateurs et donc notamment les plus récents fichiers utilisés, vous allez alors renseigner le menu variable en fonction de cette TStringList que j'appelle ici AllParam (tous les paramètres de votre application). Je suppose ici que toute ligne de la TStringList commençant par CodeFic="Fic " indique pour les caractères suivants le nom du fichier à inscrire au menu.

L'entier i pointe ici la TStringList et j les options du menu, j est donc initialisé à Prem. Pour chaque ligne de la TStingList pointée par i, je lis cette ligne dans un AnsiString LigMen (LigMen=AllParam->Strings[i++]). Si les 4 premiers caractères sont CodeFic, cela signifie (dans la codification arbitraire que j'ai proposée) qu'elle contient bien un nom de fichier à insérer au menu variable. Ici (petite astuce), j'extrais ce nom mais je rajoute au début de la chaîne son numéro d'ordre à partir de 0, ce qui fait qu'on pourra accéder à cette option en utilisant les dix chiffres du clavier de 0 à 9 car C++Builder cherche automatique un caractère de raccourci dans la propriété Caption, ici il sera tout trouvé, ce sera le chiffre ajouté en début de chaîne. Pour ce faire je calcule d'abord le nombre de caractères de la chaîne (LG=strlen(LigMen.c_str())) puis je concatène son numéro et le nom du fichier commençant à partir du 5^ème caractère (LigMen=IntToStr(i-1)+" "+LigMen.SubString(5,LG)), LigMen (ligne de menu) contient maintenant ce qu'il faudra afficher dans le menu variable. Caption prend donc la valeur LigMen et l'option sera visible. Ensuite il faut indiquer au programme l'adresse de la fonction au moment où l'utilisateur choisira cette option. Ici pour toutes les options du menu, on va à la même adresse à savoir à HistoClick (Fichier1->Items[j++]-> OnClick=HistoClick). HistoClick (nom arbitraire que je choisis) est donc une fonction membre de la classe TForm1 créée par C++Builder, il ne faudra donc pas oublier de déclarer cette fonction dans le "point h" associé.

Sinon, si vous ne faites pas cette déclaration, le compilateur vous dira [C++ Erreur] MonProj.cpp(922): E2316 '_fastcall TForm1::HistoClick(TObject *)' n'est pas un membre de 'TForm1', [C++ Erreur] MonProj.cpp(971): E2451 Symbole 'HistoClick' non défini.

Dans notre exemple, les MaxFic options rajoutées vont aller au même endroit en cas de sélection par l'utilisateur. En effet, il s'agit en fait de la même fonction à savoir traiter le fichier sélectionné. Pour savoir quelle option a été sélectionnée, on utilise la syntaxe TMenuItem *ClickedItem = dynamic_cast<TMenuItem *>(Sender);

À partir de là, ClickedItem est l'option choisie, j'en extrais de Caption le nom du fichier invoqué en lisant d'abord cette option (Choix=ClickedItem->Caption), en calculant sa longueur (LG=strlen(Choix.c_str())), en extrayant à partir de 4^ème caractère car bien sûr le chiffre qu'on a nous-même ajouté à Caption n'appartient pas au nom du fichier (Choix=Choix.SubString(4,LG)). Ici je suppose qu'on va traiter le fichier par une fonction que j'appelle TraiteFic, laquelle renvoie un numéro d'erreur en cas d'erreur (sinon 0 si pas d'erreur). Je suppose que tous les messages d'erreur sont dans une TStringList que j'appelle ici MErr, j'affiche donc le message d'erreur correspondant dans ce cas. Voici donc comment pourrait se présenter la fonction :

Notez que comme TraiteFic est appelé à modifier le menu, il sera obligatoire pour y avoir accès par programme de le déclarer comme fonction membre de TForm1 sinon vous n'aurez pas accès aux éléments. En effet, si l'utilisateur sélectionne un mauvais fichier, TraiteFic ne fera rien mais s'il en choisit un bon, ce qui sera le cas le plus fréquent, ce fichier passera en première position dans le menu variable étant le plus récemment utilisé, il faudra donc bien avoir accès au menu. Voici comment cela pourrait se passer. MemorFic reçoit le nom du fichier à mémoriser (i.e. le fichier sélectionné par l'utilisateur).

À ce stade nous avons une TStringList qui contient le nouvel ordre des fichiers, il suffit de les faire apparaître dans le menu variable ainsi que cela a été expliqué au début de cet alinéa.

Si maintenant vous décidez de programmer les options nouvelles par programme (et non de les prédéclarer), il faut utiliser d'autres syntaxes. Par exemple, rajoutons une option au moment de la création de la fenêtre principale :

Ici on a ajouté l'option Essai et elle a été associée la méthode Action à déclarer comme membre de TForm1.

Autre syntaxe, on déclare un pointeur sur un TmenuItem (TMenuItem* NewItem), on déclare une instance via l'opérateur new (NewItem=new TMenuItem(Fichier1)), à partir de là on accède à tous les champs de cet item nouveau via NewItem-> notamment pour Caption (nom qui apparaîtra dans le menu) et pour OnClick (action à exécuter en cas de sélection). Déclarons trois options par programme dans le menu Fichier1 associées respectivement à Action1, Action2 et Action3.

Les trois actions doivent être membre de TForm1 et donc déclarées dans le "point h" associé.

Vous n'avez plus qu'à écrire le code correspondant à ces actions.

À noter cet avertissement de la documentation : "L'élément renvoyé par NewItem n'a pas de propriétaire. Vous êtes responsable de la libération de sa mémoire lorsqu'elle n'est plus nécessaire. Les méthodes Delete et Remove de TMenuItem ne libèrent pas la mémoire."

C'est donc à vous de libérer la mémoire en temps voulu et aussi (pour faire bien les choses) au sortir de l'application. Par exemple, avant d'ajouter une occurrence au menu, mémorisez son indice :

Dans l'exemple précédent, cette ligne est à insérer juste après avoir inséré la ligne séparatrice. Continuons l'exemple précédent et libérons la mémoire correspondant aux trois options rajoutées, on écrira :

Observez ce fait amusant qu'on efface toujours l'option d'indice NumOp. En effet, après avoir supprimé celle indicée par NumOp, tout le monde remonte en sorte que la suivante à libérer a toujours pour indice NumOp (numéro d'option) et ainsi de suite.

51. Gestion de fenêtres-enfants

Quand un certain nombre (non connu à l'avance) de fenêtres-enfants sont susceptibles de s'ouvrir et de se fermer au cours de l'exécution d'une application, il faut gérer par programme les créations de ces fenêtres et de ses composants. Pour étudier les syntaxes de déclaration, nous partons d'un projet vierge et nous posons simplement un bouton dans la fenêtre principale, Form1 par défaut. L'idée est d'ouvrir une fenêtre-enfant à chaque click sur le bouton. On doit refuser l'ouverture de cette fenêtre si le nombre maximal est atteint. On inclura dans chaque fenêtre nouvelle un composant PaintBox. Dans les variables générales, on déclare ceci :

NbFMax est un nombre maximal de fenêtres pouvant être ouvertes simultanément à un moment donné. PBW et PBH (Paint Box Width et Paint Box Height) sont les dimensions de la PaintBox que l'on va créer à chaque création de fenêtre. FenH et FenL sont les dimensions d'une fenêtre-enfant à la création. On initialise NbFE à 0, c'est le nombre de fenêtres-enfants ouvertes pour l'instant, aucune au début de l'exécution du programme. Ensuite on déclare un tableau de NbFMax booléens. Tous les éléments de ce tableau seront initialisés à false à la construction de Form1. À chaque création de fenêtre (obtenue dans notre exemple par le click du composant bouton que l'on a posé sur notre fenêtre principale), on cherchera le premier élément à false de ce tableau puis on mettra cet élément à true. Dans ces conditions, si FE[i] est true, la fenêtre numéro i est présente dans Form1 sinon elle n'existe pas. On déclare ensuite NbFMax pointeurs de TForm et NbFMax pointeurs de TPaintBox.

Comme nous le disions, on initialise à false tous les éléments du tableau FE au moment de la construction de TForm1. C'est d'ailleurs ici qu'on initialise les variables générales d'un programme. On pourrait le faire aussi à l'événement OnCreate de la fenêtre principale mais comme C++Builder propose de lui-même la méthode Form1::Form1, on l'utilise logiquement.

Voici maintenant ce qui se passe quand l'utilisateur clique sur le bouton i.e. comment nous allons créer la fenêtre-enfant demandée.

À l'entrée de cette méthode, on commence par tester NbFE (nombre de fenêtres-enfants déjà créées et présentes à l'intérieur de Form1). Si donc NbFE est égal à NbFMax, on refuse la création de la fenêtre car nous sommes arrivés à saturation. Notez que si NbFMax est assez grand, ce cas devrait ne jamais se produire. Si NbFE est inférieur à NbFMax, on est alors sûr qu'il reste au moins un élément à false dans le tableau de booléens FE. On cherche l'indice de cet élément par la seule instruction while(FE[++N]), N étant initialisé à -1. Comme on procède par pré-incrémentation, le premier indice testé sera 0. Dès qu'un élément est trouvé faux, la boucle en while s'arrête et N sera désormais l'indice de la fenêtre que nous allons créer. N étant connu, on crée tout de suite la fenêtre par Form[N] = new TForm(Form1), ce qui signifie que le nième pointeur du tableau de pointeurs de fenêtres pointe cette fenêtre créée. On peut écrire aussi Form[N] = new TForm(this), ça marcherait tout aussi bien, les deux écritures sont équivalentes. On indique maintenant que cette fenêtre créée est parent de la fenêtre principale Form1 : Form[N]->Parent=Form1; c'est cette instruction qui fait savoir durant l'exécution que Form[N] est enfant par rapport à Form1, ce pourquoi l'enfant sera dessiné à l'intérieur du parent. Ensuite on donne les dimensions de la fenêtre-enfant Form[N]->Width=FenL; Form[N]->Height=FenH; où FenH et FenL sont des constantes arbitraires générales que nous avons déclarées. Notez que si vous voulez que la fenêtre-enfant occupe toute la place de la fenêtre-parent, il suffit d'écrire ceci (à la place des deux instructions précédentes) Form[N]->Height=Form1->ClientHeight; Form[N]->Width=Form1->ClientWidth; ce qui signifie que la hauteur de la fenêtre-enfant est égale à la hauteur de la surface cliente de la fenêtre-parent et la longueur égale à la longueur de la surface cliente. Dans ce cas, la fenêtre-enfant prend la place maximale dans son parent. Ceci nous montre que Form1->Height et Form1->Width sont les dimensions totales de Form1 alors que Form1->ClientHeight et Form1->ClientWidth sont la surface cliente excluant les bordures, c'est la zone intérieure accessible. Ensuite nous donnons les dimensions du scroll de la fenêtre-enfant par Form[N]->HorzScrollBar->Range=PBW; Form[N]->VertScrollBar->Range=PBH; où PBW et PBH sont le dimensions de la surface de la future PaintBox que l'on va créer à l'intérieur de la fenêtre-enfant. En effet, une PaintBox n'a pas de scroll, une fenêtre en a un. Si donc la PaintBox est plus grande que la fenêtre, on crée ce composant en le calant en haut à gauche de la fenêtre qui l'accueille et on active les deux scrollbars, horizontal et vertical de Form1. Le scroll sera perçu par l'utilisateur comme étant un scroll de la PaintBox, en réalité il s'agit du scroll de la fenêtre qui en tient lieu. Ensuite, il ne faut pas oublier de rendre visible la fenêtre-enfant sinon bien sûr elle n'apparaît pas à l'écran donc Form[N]->Visible=true; ensuite nous exprimons que la fenêtre-enfant est libre à l'intérieur de son parent, on pourra la déplacer et aussi changer ses dimensions visibles donc Form[N]->Align=alNone; si au lieu de alNone nous avions écrit alClient, la fenêtre-enfant aurait pris les dimensions maximales à l'intérieur de son parent et il y aurait eu impossibilité de la déplacer à l'intérieur de son parent. Nous déclarons maintenant une couleur de fond de la fenêtre-enfant Form[N]->Color=clWhite; ici, le fond de la fenêtre sera blanc. Ensuite, nous écrivons un titre à cette fenêtre-enfant qui va appraître sur la bordure en haut Form[N]->Caption="Fenêtre "+IntToStr(N+1); comme l'indice réel de fenêtre part de 0, on affiche N+1 donc pour 0 on aura fenêtre 1, pour 1 fenêtre 2 etc. Ensuite on déclare la méthode à exécuter quand la fenêtre se fermera Form[N]->OnClose=FormCloseE; cette méthode c'est FormCloseE, on utilise ici les mêmes écritures proposées par C++Builder, on rajoute simplement E pour Enfant. Comme les fenêtres créées à l'exécution ont un petit menu système par défaut, lequel se situe en haut à droite de la fenêtre, l'utilisateur pourra cliquer le x de ce menu pour fermer la fenêtre. On passera alors par la fonction membre de TForm1 FormCloseE de manière à libérer la mémoire correspondant à cette fermeture. On donne aussi la méthode à exécuter quand la fenêtre est redimensionnée Form[N]->OnCanResize=FormCanResizeE; puis on initialise le Tag de la fenêtre-enfant crée qui prend la valeur N+1 donc Form[N]->Tag=N+1; cette petite astuce nous permettra à tout moment de savoir quelle fenêtre est concernée par une action. En effet, quelle que soit la fenêtre visée, on ira toujours à la même méthode e.g. FormCloseE, il faudra donc bien savoir quelle fenêtre est concernée d'où l'utilisation du Tag qui est un nombre entier associé à un composant.

Maintenant que la fenêtre-enfant est créée avec certaines de ses propriétés initialisées par nous, on crée maintenant la PaintBox qu'on va insérer dans la fenêtre-enfant PB[N]= new TPaintBox(Form1); ce qui signifie que le Nième pointeur du tableau PB pointe cette nouvelle PaintBox. On dit maintenant au programme que cette PaintBox est un composant de la fenêtre-enfant créée PB[N]->Parent=Form[N]; i.e. le parent de la PaintBox est la fenêtre-enfant. On indique ensuite les dimensions de la PaintBox PB[N]->Width=PBW; PB[N]->Height=PBH; où PBW et PBH sont des constantes que nous avons déclarées. On initialise aussi le Tag de la PaintBox PB[N]->Tag=N+1; ainsi, à tout moment, on saura par cet entier de quelle PaintBox il s'agit en cas d'action sur elle. On indique maintenant la méthode à exécuter en cas de Paint PB[N]->OnPaint=PaintE; c'est là qu'on va dessiner dans la PaintBox. On indique aussi la méthode à exécuter quand l'utilisateur appuie sur le bouton de la souris PB[N]->OnMouseDown=MouseDownE; ensuite on dit que la PaintBox est visible PB[N]->Visible=true; elle l'est d'ailleurs par défaut, on peut ne pas écrire cette instruction. Puis on indique le type d'alignement de la PaintBox par rapport à son parent, ici il s'agira de alClient, PB[N]->Align=alClient; cela signifie que la PaintBox prend toute la place dans son parent.

La fenêtre-enfant est maintenant créée, on met donc à true le Nième élément de notre tableau de booléens FE[N]=true; et on incrémente le nombre de fenêtres-enfants présentes dans Form1, NbFE++;

Voici comment nous procédons au moment où une fenêtre se ferme. Cet événement survient parce que l'utilisateur a cliqué le petit x du menu système de la fenêtre-enfant. Au moment de la création de la fenêtre, nous avons déclaré FormCloseE comme étant la méthode à exécuter liée à l'événement OnCLose.

On affiche un message fermeture. Dans une vraie application, on n'affiche évidemment rien mais cet affichage vous prouve que la méthode est exécutée. Remarquez bien la syntaxe pour lire le Tag de la fenêtre : int i=((TComponent*)Sender)->Tag-1; dans ces condition, i représente l'indice de la fenêtre à détruire. On détruit donc la PaintBox puis la fenêtre (dans cet ordre bien sûr car la PaintBox est un enfant de la fenêtre), l'élément du tableau de booléens passe à false, libérant cet indice pour une future ouverture et enfin, le nombre de fenêtres-enfants est décrémenté. Comme vous le constatez, c'est le système qui se charge de la destruction visuelle de la fenêtre mais la libération mémoire est à notre charge.

Notons qu'on peut s'épargner le tableau de booléens FE, il suffit pour cela d'initialiser les pointeurs Form[i] à NULL et de remettre chaque pointeur à NULL juste après le delete Form[i] au moment de la fermeture de la fenêtre. Ainsi pour tout i, si Form[i]==NULL, la fenêtre n'existe pas sinon elle existe, ce qui simule bien le tableau de booléens dont nous avons besoin.

Nous allons maintenant peindre à l'intérieur de chaque PaintBox. Nous avions déclaré PaintE comme méthode de l'événement OnPaint. Nous écrivons donc cette méthode qui nous permettra simplement de constater la persistance du contenu de la PaintBox ainsi que la validité du scroll.

Encore une fois, à partir du Tag du composant, on en déduit l'indice par décrémentation car l'indice part de 0 mais le Tag de 1. i étant cet indice, on peint dans PB[i]. On affiche ici le numéro de la fenêtre, on affiche trente fois ce numéro et à chaque fois un nombre allant de 1 à 30. La coordonnée en x avance à chaque itération de 150 pixels. Ceci a simplement pour vocation de montrer que chaque fenêtre connaît son numéro, et un affichage très long en x montrera que le scroll est correct.

Voici maintenant ce qui se passe sur OnMouseDown.

On affiche simplement les coordonnées de click, cela vous prouve qu'il s'agit bien des coordonnées de la fenêtre cliquée. On affiche aussi le numéro du Tag pour montrer qu'à tout moment, on connaît la fenêtre visée par son indice.

Voici ce que nous proposons si l'utilisateur modifie la taille de la fenêtre (méthode FormCanResizeE déclarée en relation à l'événement OnCanResize).

On simule ainsi l'événement OnMaximize qui n'existe pas. La méthode nous envoie les nouvelles dimensions demandée par l'utilisateur. L'expérience montre que si NewWidth vaut Width et s'il y a une différence de 19 pixels entre la nouvelle hauteur avec la hauteur de la fenêtre, cela signifie que l'utilisateur a cliqué sur la petit carré du menu système pour maximaliser la dimension de la fenêtre. On ne fait que réajuster ces dimensions de manière à ce que la fenêtre-enfant s'encastre parfaitement dans son parent en soustrayant 5 unités sinon l'encastrement n'est pas parfait. La raison en est sans doute de nous rappeler la présence d'un scrollbar dans la fenêtre, on signifie par là que l'image n'est vue que partiellement. Si la fenêtre n'a pas de scrollbar, l'imbrication suite à une demande de maximalisation entre de la fenêtre-enfant à l'intérieur de son parent est parfaite, il n'est alors pas nécessaire d'intervenir logiciellement.

Voici maintenant ce qui se passe à la destruction de la fenêtre principale. Cet événement survient à la fin de l'exécution. Il convient de libérer la mémoire allouée.

Pour chaque élément booléen du tableau, on ne fait rien s'il est à false car la fenêtre correspondant à cet indice n'existe pas mais on supprime la PaintBox puis la fenêtre (dans cet ordre car la PaintBox appartient à la fenêtre) si l'élément est à true.

Bien entendu, toutes les méthodes liées aux composants sont membres de TForm1 qui apparaît donc comme suit:

Petite astuce: pour ne pas se tromper dans les arguments d'une méthode que vous voulez associez à un composant, le mieux consiste à la faire créer automatiquement par C++Builder puis procéder à un copier-coller. Par exemple, on veut rajouter l'événement OnMouseDown pour la fenêtre-enfant. On double-clique sur l'événement OnMouseDown de Form1 à seule fin d'en créer la syntaxe d'appel. Là-dessus, C++Builder vous a créé le gestionnaire d'événement mais il a aussi déclaré la méthode dans l'en-tête associé (le .h). Faisons Ctrl-F6 qui fait afficher cet entête, on peut aussi afficher l'en-tête du fichier cpp en cours par le menu surgissant (click à droite), c'est la première occurrence. Vous voyez que C++Builder a déclaré l'événement dans la section "published". Copiez-collez cette déclaration dans la section "public" et rajoutez simplement E à la fin (pour Enfant). Ensuite vous revenez au cpp, vous copiez-collez le gestionnaire créé par C++Builder, vous ajoutez également un E. Ainsi, vous avez créé un événement et vous êtes certain que la syntaxe sera correcte puisque c'est celle créée par le progiciel. Ensuite, à la compilation, vous verrez que l'événement OnMouseDown de Form1 a disparu, ce qui est logique puisque vous n'avez rien écrit à l'intérieur, vous n'aviez créé le gestionnaire d'événement OnMouseDown de Form1 que pour en avoir la syntaxe. Il en ira de même pour tout événement. S'il s'agit d'un événement associé à un composant qui ne se trouve pas sur votre fiche, rajoutez-le temporairement, créez le gestionnaire d'événement en double-cliquant sur l'événement voulu, copiez-collez la déclaration dans le .h et dans le .cpp et personnalisez le nom de la méthode, vos syntaxes seront correctes, vous pouvez ensuite virez le composant de la fiche puisqu'en réalité vous n'en n'avez pas besoin.

52. Le composant ScrollBar

Dans l'alinéa précédent, nous avons créé des fenêtres-enfants à l'intérieur desquelles on a inclus une PaintBox. On peut se poser la question de savoir en quoi cette PaintBox était utile puisqu'en réalité, toute fenêtre ayant un canvas, on dispose avec la seule fenêtre de toutes les fonctions de dessin. Cette PaintBox n'avait en fait qu'une seule utilité, celle de faire gérer automatiquement par C++Builder le scroll horizontal et vertical. En effet, la fenêtre-enfant créée avait de petites dimensions FenH et FenL, alors que la PaintBox avait une très grande surface virtuelle de dessin de PBH*PBW. Comme la PaintBox est enfant de la fenêtre (elle-même enfant de la fenêtre principale), nous avons déclaré la propriété Range des scrolls de la fenêtre-enfant à égalité avec les dimensions virtuelles de la PaintBox (Form[N]->HorzScrollBar->Range=PBW; Form[N]->VertScrollBar->Range=PBH;). C'est ce mécanisme qui fait qu'un scroll est géré automatiquement par C++Builder et c'est pourquoi la PaintBox était utile. C'est l'initialisation des propriétés Range qui rend visibles et utilisables les scrollbars.

Si maintenant vous voulez gérer vous-même le scroll, il faut alors utiliser un composant TScrollBar. Cela peut s'avérer nécessaire dans le cas où (par exemple) votre surface de dessin excède les possibilités d'une PaintBox. Une PaintBox a des dimensions et donc des coordonnées sur 15 bits, on va donc de 0 à 32767 pour les coordonnées en x et en y. Si vous vouliez gérer des coordonnées quasi illimitées (e.g. sur 32 bits), vous ne pouvez plus utiliser le scroll automatique. Dans ce cas, on se contente de déclarer une fenêtre à l'intérieur de laquelle on crée deux scrollbars, l'un horizontal, l'autre vertical et la surface de dessin n'est que la zone client de la fenêtre. Dans ce cas, la création d'une PaintBox dans la fenêtre n'est plus nécessaire puisque sa surface de dessin coïnciderait avec la zone client de la fenêtre. Cela dit, si votre programme gère ces deux modes, vous auriez intérêt malgré tout à déclarer la PaintBox même si sa dimension coïncide avec la zone client de sa fenêtre-parent et ce, pour éviter d'avoir différentes syntaxes suivant que vous dessiniez dans le canvas de la fenêtre (avec des syntaxes du type Form[N]->Canvas, je reprends ici les déclarations de l'alinéa précédent) ou dans le canvas d'une PaintBox (avec des syntaxes du type PB[N]->Canvas). Dans tous les cas, on déclarerait la PaintBox, la syntaxe d'accès est alors unique.

Reprenons les éléments de l'alinéa précédent, et voyons comment nous pourrions procéder pour gérer nous même le scroll. D'une part, on déclarerait deux fois NbFMax pointeurs vers des composants de ce type.

En effet, si on autorise l'ouverture de NbFMax fenêtres-enfants, on aura 2*NbFMax pointeurs de scrollbar car pour chaque fenêtre il y aura un scrollbar horizontal et un vertical. Ainsi pour la fenêtre d'indice i, le pointeur du scrollbar horizontal sera SB[2*i] et celui du vertical sera SB[2*i+1]. Ensuite, la fenêtre d'indice N ayant été créée via Form[N] = new TForm(Form1); et certaines de ses propriétés initialisées, on crée maintenant les deux scrollbars,

On exprime ensuite que ces scrollbars appartiennent à la fenêtre-enfant créée,

On initialise aussi les tags pour pouvoir se repérer logiciellement,

On dit ensuite que le scrollbar d'incice 2*N est horizontal et l'autre d'indice 2*N+1 vertical,

On indique ensuite la façon dont le scrollbar se positionne par rapport à son parent, alBottom pour l'horizontal (il va donc se placer sur toute la longueur en bas de la fenêtre) et alRight pour le vertical (il va se placer à droite sur toute la hauteur de la fenêtre)

On simule ainsi un double scrollbar classique mais ils sont maîtrisés logiciellement. Ensuite on associe une méthode pour l'événement OnScroll,

Ici nous créons deux méthodes, une pour le scroll horizontal et l'autre pour le vertical. On aurait pu aussi n'en créer qu'une seule et faire la distinction à l'intérieur de la méthode. Mais dans ce cas, il faudrait initialiser autrement les tags. Ici nous avons donné au tag le numéro de fenêtre, on ne peut donc pas distinguer le scrollbar horizontal du vertical puisqu'ils ont le même tag. Il faudrait que le tag contienne l'indice du tableau SB, SB[2*N]->Tag=2*N; et SB[2*N+1]->Tag=2*N+1; auquel cas, l'indice du tag nous donne et le numéro de fenêtre et la position du scrollbar invoqué, horizontal ou vertical (pair pour horizontal, impair pour vertical), dans ces conditions une seule méthode de scroll suffirait. Pour savoir si le bouton du scroll est relâché, on teste ScrollCode avec la constante scPosition et la propriété Position du scrollbar nous donne sa position. Considérons POS comme une variable générale du type unsigned int, on renseigne cette variable dans la méthode avec la position du scroll. La variable booléenne Horiz dira si la scroll est horizontal (true) ou vertical (false). Puis on crée par programme un événement paint en appelant simplement la méthode. Voici comment on pourrait programmer ces méthodes.

Dans ces conditions, la méthode Paint est appelée. On connaît l'indice de la fenêtre concernée, on connaît la position du scroll (POS), on sait s'il s'agit du scrollbar horizontal ou vertical (Horiz), en fonction de toutes ces données, on repeint la zone concernée de la fenêtre par programme.

TTabSheet *pPage = new TTabSheet(PageControl1);

pPage->PageControl = PageControl1;

Pour afficher dans l'onglet une chaîne on utilise comme à l'accoutumé la propriété Caption (pPage->Caption="Chaîne" où pPage est du type TTabSheet c'est-à-dire un onglet du composant PageControl1), on lui affecte un AnsiString. Le nombre de pages inclus dans le composant est égal à PageControl1->PageCount, c'est un entier, la page active à un moment donné est PageControl1->ActivePageIndex, c'est un entier qui va de 0 à n-1 (n étant le nombre de pages i.e. PageControl1->PageCount). La ième page sera accessible via PageControl1->Pages[i].

__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner)
{
PageControl1->Visible=false;
}

void __fastcall TForm1::Button1Click(TObject *Sender)
{
PageControl1->Visible=true;
TTabSheet *pPage = new TTabSheet(PageControl1);
pPage->PageControl = PageControl1;
pPage->Caption = "Page " + IntToStr(PageControl1->PageCount);
}

void __fastcall TForm1::PageControl1Change(TObject *Sender)
{
AnsiString A;
A="Il y a "+IntToStr(PageControl1->PageCount)+ " page";
if(PageControl1->PageCount>1) A=A+"s";
A=A+" et la page activée est la page numéro "+
IntToStr(PageControl1->ActivePageIndex);
Application->MessageBox(A.c_str(),"OK",MB_OK);
}

void __fastcall TForm1::Button2Click(TObject *Sender)
{
if(PageControl1->PageCount)
{
delete PageControl1->Pages[PageControl1->ActivePageIndex];
for(int i=0;i<PageControl1->PageCount;i++)
PageControl1->Pages[i]->Caption="Page"+ IntToStr(i+1);
}

if(!PageControl1->PageCount) PageControl1->Visible=false;
}

void __fastcall TForm1::FormDestroy(TObject *Sender)
{
for(int i=0;i<PageControl1->PageCount;i++)
delete PageControl1->Pages[i];
}

Il est probable, puisque ce composant appartient à Form1, que cette précaution ne soit pas nécessaire et qu'on pourrait s'en passer. Cela dit, il est toujours bon de prendre pour habitude de supprimer par delete ce qui a été créé par new, vous êtes ainsi persuadé d'une excellente gestion mémoire. Vous remarquerez à l'exécution que deux petits boutons fléchés apparaissent à droite du composant dès que tous les onglets ne peuvent plus s'afficher en totalité, ces flèches vous permettent de naviguer en avant et en arrière. N'oubliez pas en testant à l'exécution de cliquer un onglet quelconque pour faire apparaître le message-témoin programmé. À noter enfin que la propriété ActivePageIndex est aussi en écriture, ainsi pour activer logiciellement le premier onglet on écrira PageControl1->ActivePageIndex = 0; et pour activer le dernier PageControl1->ActivePageIndex = PageControl1->PageCount-1; si vous voulez que cette initialisation se fasse à la création, dans l'inspecteur d'objets sélectionnez "PageControl1" puis choisissez la page voulue (en général la première) dans le menu déroulant proposé à la propriété ActivePage, à l'exécution du programme, la page choisie sera sélectionnée.

void __fastcall TForm1::ToolButton1Click(TObject *Sender)
{
Application->MessageBox("Bouton1", "ok", MB_OK);
}

void __fastcall TForm1::ToolButton2Click(TObject *Sender)
{
int x=Form1->Left+ToolBar1->Left+ToolButton2->Left+5;
int y=Form1->Top+ToolBar1->Top+ToolButton2->Top+50;
PopupMenu1->Popup(x,y);
}

__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner)
{
Graphics::TBitmap* B1,*B2,*B3;

B1 = new Graphics::TBitmap();
B2 = new Graphics::TBitmap();
B3 = new Graphics::TBitmap();

B1->LoadFromFile("Bitmap1.bmp");
B2->LoadFromFile("Bitmap2.bmp");
B3->LoadFromFile("Bitmap3.bmp");

ImageList1->Add(B1,NULL);
ImageList1->Add(B2,NULL);
ImageList1->Add(B3,NULL);

delete B1;
delete B2;
delete B3;
}

__fastcall TForm1::TForm1(TComponent* Owner):TForm(Owner)
{

/* Nombre d'images ici 3 pour notre test*/
const int NbBM=3;

/* Déclaration d'une TStringList qui contiendra
le nom des bitmaps */
TStringList *SL=new TStringList;

/* Déclaration d'un bitmap unique */
Graphics::TBitmap *BM = new Graphics::TBitmap();

/* On ajoute dans la StringList le nom des bitmaps*/
SL->Add("Bitmap1.bmp");
SL->Add("Bitmap2.bmp");
SL->Add("Bitmap3.bmp");

/* Pour chaque nom de la StringList, on charge notre
bitmap et on ajoute son image à la liste d'images */
for(int i=0;i<NbBM;i++)
{
BM->LoadFromFile(SL->Strings[i]);
ImageList1->Add(BM,NULL);
}

/* on supprime la stringList et le bitmap*/
delete SL;
delete BM;
}

__fastcall TForm1::TForm1(TComponent* Owner):TForm(Owner)
{
const int NbBM=3;
char Liste[][50]={"Bitmap1.bmp","Bitmap2.bmp","Bitmap3.bmp"};
Graphics::TBitmap *BM = new Graphics::TBitmap();

for(int i=0;i<NbBM;i++)
{
BM->LoadFromFile(Liste[i]);
ImageList1->Add(BM,NULL);
}

delete Liste;
delete BM;
}

#include <vcl.h>
#pragma hdrstop

#include "Unit04.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
const int NbFenMax=3;
TForm1 *Form1;
TForm *F[NbFenMax];

__fastcall TForm1::TForm1(TComponent* Owner):TForm(Owner)
{
for(int i=0;i<NbFenMax;i++) F[i]=NULL;
}

Cette petite astuce nous permettra de savoir pour un indice donné s'il est associé ou non à une fenêtre. Une des options de notre menu sera "Nouveau" pour créer une fenêtre. On cherchera dans le tableau le premier indice libre entre 0 et NbFenMax-1. Voici cette petite fonction :

int __fastcall Prem()
{
for(int i=0;i<NbFenMax;i++) if(F[i]==NULL) return i;
return -1;
}

Vous voyez qu'on boucle dans notre petit tableau de pointeurs, si l'indice lu est à NULL, cela signifie qu'il est libre et alors on sort tout de suite avec cet indice sinon on s'en retourne avec -1 qui indiquera au programme appelant qu'il est impossible d'ouvrir une nouvelle fenêtre parce que le maximum autorisé a été atteint. Dans nos tests, NbFenMax est à trois pour tester précisément ce cas mais si NbFenMax est assez grand, il est peut probable que cela se produise. Pour les puristes, j'accorde que l'on peut écrire if(!F[i]) au lieu de if(F[i]==NULL), les deux syntaxes sont équivalentes.

Double-cliquons dans l'option "Nouveau" de notre menu principal pour créer le gestionnaire d'événement correspondant et programmons l'ouverture d'une fenêtre-enfant.

void __fastcall TForm1::NouveauClick(TObject *Sender)
{
int i=Prem();
if (i==-1) Application->MessageBox("Refusé", NULL, MB_OK);
else
{
F[i]=new TForm(Form1);
F[i]->FormStyle=fsMDIChild;
F[i]->Color=clWhite;
F[i]->Caption="Fenêtre "+IntToStr(i+1);
F[i]->Tag=i;

F[i]->OnClose=FormCloseE;
}
}

Nous appelons d'abord notre fonction Prem qui nous renvoie le premier indice disponible du tableau de pointeurs de fiches. Si cet indice i est -1, la demande est refusée car nous n'avons plus de pointeurs disponibles, tous pointent une fenêtre-enfant. Dans ce cas, on affiche un message dans un MessageBox et on quitte la méthode. Sinon, l'indice i est valide, on crée alors la fenêtre via l'opérateur new puis on indique immédiatement qu'elle est du type fsMDIChild. Dans ces conditions, la fenêtre viendra se dessiner dans la zone client de son parent. Ensuite on donne la couleur de la fenêtre (ici clWhite pour la différencier de son parent en gris par défaut), puis le titre de la fenêtre via son numéro, on ajoute simplement 1, on aura donc "Fenêtre 1" pour l'indice 0, "Fenêtre 2" pour l'indice 1 et ainsi de suite. Ensuite on initialise son Tag avec l'indice du tableau, cela nous permet à tout moment de savoir quel est l'indice concerné si besoin est. Ensuite on indique que la méthode FormCloseE est associée à l'événement OnClose.

Créons cette méthode OnCloseE. Comme on ne peut pas connaître toutes les syntaxes, le mieux est d'en faire créer le prototype par C++Builder. Pour ce faire, sélectionnez Form1 puis double-cliquez l'événement "OnClose" de Form1. C++Builder vous en a créé la syntaxe. Revenez au source et faites maintenant ctrl-F6 (contrôle F6) pour afficher l'en-tête. Vous voyez que C++Builder a déclaré cette méthode dans la classe Form1, copiez-collez cette méthode dans la section "public" et rajouter un E pour Enfant à son nom, à partir de OnClose, on obtient OnCloseE. Revenez au source C++ et copiez-collez la méthode OnClose à la suite du source et rajoutez également le E à son nom. Par ces deux opérations, vous venez de créer la méthode OnCloseE associée à l'événement OnClose de la fenêtre-enfant. Voici comment nous allons programmer cette méthode.

void __fastcall TForm1::FormCloseE(TObject *Sender, TCloseAction &Action)
{
int i=MDIChildren[0]->Tag;
delete F[i];
F[i]=NULL;
}

void __fastcall TForm1::FermerClick(TObject *Sender)
{
if(MDIChildCount)
{
int i=MDIChildren[0]->Tag;
delete F[i];
F[i]=NULL;
}
}

void __fastcall TForm1::FormCloseE(TObject *Sender,TCloseAction &Action)
{
FermerClick(Sender);
}

Si on choisit l'inverse c'est-à-dire FermerClick qui appelle FormCloseE, il faudrait envoyez à FormCloseE une variable de type TCloseAction, une variable et non une constante (e.g. caMinimize qui est d'ailleurs la valeur par défaut pour une fenêtre-enfant MDI, voir l'aide en ligne pour les différentes valeurs possibles de type TCloseAction) puisque sa déclaration dans FormCloseE se fait avec l'opérateur &. Si dans FermerClick on écrivait pas exemple FormCloseE(Sender, caMinimize), on aurait alors un warning du compilateur disant "un temporaire a été utilisé pour le paramètre Action". Pour éviter ce warning même s'il n'est pas fatal, il faudrait déclarer pour rien une variable par exemple A du type TCloseAction et écrire alors FormCloseE(Sender, A); c'est pour éviter ces difficultés d'ailleurs sans importance que nous avons opté pour l'appel inverse.

Il est bon de détruire par delete toutes les fenêtres-enfants, cela doit se faire à l'événement OnCloseQuery de Form1 (car Form1 doit encore exister pendant la destruction des fenêtres-enfants). Double-cliquez sur cet événement pour créer le gestionnaire d'événement et procédez comme suit :

void __fastcall TForm1::FormCloseQuery(TObject *Sender, bool &CanClose)
{
for(int i=0 ; i<MDIChildCount; i++) delete MDIChildren[i];
}

On utilise la variable gérée par C++Builder MDIChildCount qui représente le nombre de fenêtres-enfants ouvertes à ce moment-là. On aurait pu utiliser aussi notre tableau, par exemple :

void __fastcall TForm1::FormCloseQuery(TObject *Sender, bool &CanClose)
{
for(int i=0;i<NbFenMax;i++) delete F[i];
}

Faites F9 pour compiler-exécuter, vous constatez que vous pouvez ouvrir des fenêtres-enfants et qu'en cas de maximalisation, le menu système de la fenêtre vient bien se dessiner à droite du menu principal, ce qui est le comportement MDI type, et le nom de la fenêtre active vient s'inscrire sur la bordure de la fenêtre principale. Si vous préférez que les fenêtres-enfants soit maximalisées dès la création, il suffit de rajouter (par exemple juste après F[i]->Tag=i;) dans la méthode TForm1::NouveauClick (voir ci-dessus) l'instruction :

F[i]->WindowState=wsMaximized;

La fenêtre-enfant sera maximalisée dès sa création. Une propriété intéressante de la fenêtre principale est WindowMenu. Puisque nous avons un menu principal (quasi obligatoire rappelons-le pour les applications MDI), on aura comme dans Word une option "Fenêtre", en général placée tout à droite du menu, juste avant le point d'interrogation donnant accès à la rubrique d'aide. Cette option "Fenêtre" sera censée offrir diverses fonctions relatives à l'agencement des fenêtres. Si vous donnez à WindowMenu cette option "Fenêtre" (il suffit pour cela de la choisir dans le menu déroulant proposé) du menu principal, la gestion des fenêtres ouvertes se fera automatiquement c'est-à-dire qu'à l'exécution vous aurez la liste tenue à jour des fenêtres disponibles avec un petit signe indiquant la fenêtre active avec la possibilité d'en activer une autre puisque ces occurrences font partie du menu. C'est assez pratique puisque vous n'avez qu'à initialiser la propriété WindowMenu avec une option du menu principal pour que ça marche. C++Builder propose dans la liste déroulante associée à WindowMenu toutes les options du menu principal mais en réalité seule une fonction visible à l'écran (c'est-à-dire première d'une colonne dans le constructeur de menu) fait fonctionner ce mécanisme.

Remarquons que dans notre exemple, aucune fenêtre-enfant n'est créée à l'entrée de notre application. Si vous désirez en créer une au tout début de l'exécution, le mieux est de disposer d'une "Liste d'actions" (Composant TActionList, voir alinéa suivant), de créer l'action Ouverture (sans catégorie précise) et d'initialiser la propriété Action de la fenêtre principale Form1 avec cette méthode. D'ailleurs, dès que vous avez une liste d'actions (c'est-à-dire dès que le composant TActionList fait partie de votre projet étant déposé dans la fenêtre principale), un menu déroulant automatique en regard de la propriété Action vous invite à sélectionner une action parmi la liste. Ainsi, une fenêtre-enfant sera ouverte dès l'entrée dans l'application. Voyons donc comment fonctionne ce composant très utile et très pratique dont la vocation est de centraliser les actions importantes d'une application.

Ce composant se situe sous l'onglet "standard" de la palette de composants, il se trouve normalement en dernière position, on y voit un petit rectangle à l'intérieur duquel on lit ok et une petite flèche blanche déroulant un menu. Ce petit logo est très explicite car si un bouton fait la même chose qu'une option du menu, on a tout intérêt à centraliser l'action dans une "liste d'actions". L'idée est la suivante. Pour un objet donné par exemple un bouton ou une option d'un menu, il existe une action particulière plus importante que les autres associée à cet objet, en général l'action en relation au click de l'objet. C'est pourquoi pour chaque objet il existe la propriété "Action" qui est d'ailleurs la toute première étant donné que les propriétés sont données par ordre alphabétique dans l'inspecteur d'objets. Si vous disposez d'un composant TListAction et que vous y déclariez des actions, vous aurez alors à disposition un menu déroulant à cette propriété Action et il vous suffit de choisir une action pour l'associer à cet objet. Cela vous dispense d'avoir à écrire un gestionnaire d'événement notamment OnClick. Cela dit C++Builder vous confirme dans les événements que l'action est bien liée à OnClick. Bien entendu, si vous n'utilisez pas ce composant, vous pouvez aussi appeler une méthode, comme nous l'avons fait dans l'alinéa précédent, pour éviter de dupliquer du code mais l'idée est plus de centraliser les actions. Si plusieurs objets font une certaine action, vous saurez que cette action se trouve dans la liste d'actions, vous n'aurez pas à chercher quelle méthode centralise ce code.

Ce composant est très simple à utiliser. On le dépose sur la fiche principale. Pour créer une action, on double-clique sur le composant ou bien on clique à droite en le pointant et on choisit "éditeur de liste d'actions". On tombe sur une petite fenêtre divisée en deux parties, une partie pour les catégories d'actions et l'autre pour le nom de ces actions. En effet, C++Builder a préparé pour vous des actions standard qu'on peut regrouper sous quatre catégories. Pour observer ces catégories, cliquez la petite flèche à côté de l'icône jaune (la bulle d'aide affiche "Nouvelle action") et choisissez "nouvelle action standard". Là, on vous affiche toutes les actions standard disponibles préfixées respectivement par TData, TEdit, THelp et TWindow donc des actions concernant respectivement les données, l'édition, l'aide et les fenêtres (à l'exception de la première qui est TAction et qui représente le type d'action neutre, sans catégorie). Annuler pour sortir de ce tableau puis cliquez sur l'icône jaune pour insérer une nouvelle action sans catégorie (ou bien appuyez sur la touche ins du clavier). On vous affiche "Action1" en regard de la catégorie "vide" (i.e. pas de catégorie particulière). Nous allons créer une action pour créer une fenêtre-enfant MDI, nous reprenons donc les éléments de l'alinéa précédent. Dans Name, nous donnons un nom à cette action par exemple "Ouvre" (nous ne choisissons pas "Nouveau" car on suppose que ce nom est déjà utilisé dans notre menu, voir alinéa précédent). Revenez à l'éditeur de liste d'actions et cliquez ce nouveau nom "Ouvre", C++Builder vous crée la méthode correspondant à cette action.

void __fastcall TForm1::OuvreExecute(TObject *Sender)
{

}

void __fastcall TForm1::FermetureExecute(TObject *Sender)
{
if(MDIChildCount)
{
int i=MDIChildren[0]->Tag;
delete F[i];
F[i]=NULL;
EtatFen[i]=0;
}
}

Dans ces conditions, il nous suffit d'appeler cette action dans la méthode FormCloseE.

void __fastcall TForm1::FormCloseE(TObject *Sender,TCloseAction &Action)
{
FermetureExecute(Sender);
}

Notons au passage que nous n'aurions pas pu associer directement l'événement OnClose à FermetureExecute (c'est-à-dire écrire au moment de la création de la fenêtre-enfant F[i]->OnClose=FermetureExecute;) à cause de l'argument Action supplémentaire dans FormCloseE, les deux prototypes sont incompatibles. Un moindre mal consiste à appeler l'action de la liste comme proposé ci-dessus. En revanche, pour l'option "Fermer" de notre menu, on associe sa propriété Action avec FermetureExecute.

En résumé, quand vous développez avec une TActionList, vous créez d'abord votre action dans la liste d'actions et ce n'est qu'ensuite que vous associez cette action à la propriété Action d'un objet, en général plusieurs, car une même action s'effectue souvent par des chemins différents. Ainsi, toutes les actions de votre application sont centralisées et donc faciles à retrouver. Un autre avantage de passer par des listes d'actions est de bénéficier de comportements automatiques des composants sans aucune programmation supplémentaire. Par exemple, si un bouton est lié à une opération de fermeture de fenêtre-enfant dans une application MDI, il sera automatiquement désactivé s'il s'y a plus de fenêtre-enfant présente dans la fenêtre-parent (i.e. si MDIChildCount est nul), l'option de menu qui fermerait une fenêtre-enfant serait, elle aussi, désactivée.

Remarquons pour terminer qu'on ne peut pas insérer ni ajouter d'actions logiciellement. Le mieux, pour simuler un tel effet, est d'insérer un certain nombre d'actions à la main sans rien faire d'autre, cela réserve l'espace de déclaration à ces actions. Par exemple, on initialise normalement la section commençante de la liste d'actions puis on en insère un certain nombre en plus à la suite sans rien faire d'autre. On repère l'indice à partir duquel commence la section de ces actions non encore initialisées sachant que les indices commencent à partir de zéro (il y a ActionList1->ActionCount actions dans la liste indicées de 0 à ActionList1->ActionCount-1). Maintenant, pour affecter l'action d'indice n à une méthode du programme, on écrira :

ActionList1->Actions[n]->OnExecute=Nom_de_la_fontion_a_executer;

Si l'on veut associer le click d'un bouton à l'action d'indice n de la liste, on écrira :

Button->OnClick=ActionList1->Actions[n]->OnExecute;

Cette fonction renvoie les coordonnées réelles par rapport à l'écran, cela peut être utile dans certains cas, par exemple quand on veut déterminer la position d'un menu surgissant lequel est fonction de la position d'une ToolBar déplacée. Il faut déclarer une variable P de type POINT, donner &P en argument (ce qui est logique puisque la fonction doit retourner le résultat) et interroger P.x et P.y (x et y en minuscule). Ci-après l'appel de GetCursorPos suite à un click dans la fiche principale. Les coordonnées sont les coordonnées réelles par rapport à l'écran et non plus par rapport à la fiche.

void __fastcall TForm1::FormClick(TObject *Sender)
{
POINT P;
if(GetCursorPos(&P))
{
AnsiString A=IntToStr(P.x)+" "+IntToStr(P.y);
Application->MessageBox(A.c_str(),"ok",MB_OK);
}
}

En principe, ainsi que nous l'avons dit dans notre vue d'ensemble au début de ces "remarques", on initialise une application au moment du constructeur de la fiche principale TForm1::TForm1.

__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
/* initialisation ici de l'application */
}

Si, pour une raison ou une autre, vous devez prendre la main avant la construction de la classe TForm1, il faut alors utiliser Application->Initialize(). Entrez dans C++Builder et sauvez le projet vide unitxx et projetxx. Ensuite faites "Voir|Unités" (contrôle F12) et choisissez projetxx. C'est le programme maître créé par C++Builder lui-même. Vous constatez que la première instruction est Application->Initialize().

#include <vcl.h>
#pragma hdrstop
USERES("Project1.res");
USEFORM("Unit1.cpp", Form1);
//--------------------------------------------------------------------
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
Application->Initialize();
Application->CreateForm(__classid(TForm1), &Form1);
Application->Run();
}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
return 0;
}

En réalité, Application->Initialize() ne fait rien (car InitProc est initialisé à NULL par défaut), on peut même supprimer cette instruction pour le cas où l'on n'en a pas besoin. Si toutefois vous voulez prendre la main avant la construction de TForm1, il faut initialiser la variable InitProc avec le nom d'une fonction d'initialisation, c'est cette fonction qui sera exécutée. Vérifions. Nous allons initialiser InitProc avec la fonction InitAppli laquelle ne fait que nous afficher un message, ce qui nous prouvera que la fonction est effectivement exécutée.

#include <vcl.h>
#pragma hdrstop
USERES("Project10.res");
USEFORM("Unit10.cpp", Form1);
void InitAppli(void);
//------------------------------------------------------------------
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
InitProc=InitAppli;
Application->Initialize();
Application->CreateForm(__classid(TForm1), &Form1);
Application->Run();
}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
return 0;
}
//-----------------------------------------------------------
void InitAppli()
{
Application->MessageBox("Initialisation de l'application","ok",MB_OK);
}

Quand une instruction risque de se retrouver en erreur, on la protège par l'instruction try et on gère l'erreur par catch. Le programme maître type proposé par C++Builder (voir alinéa précédent) en est un exemple. Il faut juste remarquer que par défaut cette gestion ne fonctionne pas sous C++Builder c'est-à-dire finalement en mode debug mais seulement en mode réel i.e. quand vous cliquez directement l'exe et ce, parce C++Builder détourne les exceptions en premier. Si vous voulez quand même tester sous C++Builder le comportement de telles exceptions, il faut faire "Outils|Options du débogueur" et décocher la case "Arrêter sur exceptions C++" en bas du formulaire puis valider. Dans ces conditions, vous pouvez tester les exceptions.

Imaginons que l'on veuille tester la création d'une zone mémoire par new, on programmera ceci :

try
{
PtrFic=new char[Longueur];
}
catch (...)
{
Application->MessageBox("Problème d'allocation dynamique",NULL,MB_ICONERROR);
}

où Longueur est une variable ou constante arbitraire. Si l'allocation réussit, le programme continue sinon il passe par le gestionnaire inauguré par catch car il y a une exception du type bad_alloc. Pour vérifier ce point, vous donnez à Longueur un nombre très grand, l'allocation sera alors refusée et vous constaterez qu'un message vous est affiché. Une fois ce test réalisé, vous n'avez plus qu'à recocher la case "Arrêter sur exceptions C++" pour continuer votre développement car il est préférable de travailler en mode protégé.

Il s'agit d'un draw dans un rectangle. La méthode Draw ne fait que recopier tel quel un dessin (e.g. un bitmap dans un canvas) alors que StretchDraw recopie dans un rectangle. Il en résulte que si le rectangle est de dimension identique au bitmap à recopier, StretchDraw équivaut alors à un draw simple. Mais si le rectangle est de dimension différente, le bitmap est alors plus grand ou plus petit, on programme facilement des zooms de cette façon.

Voici un petit exemple. Nous déclarons un bitmap Bmp à l'intérieur duquel nous écrivons le mot Essai. Nous déclarons un rectangle R que nous initialisons en faisant coïncider le point en haut à gauche avec celui en bas à droite, autant dire que ce rectangle est néant pour le moment. On met un bouton sur Form1. À chaque click du bouton, nous allons d'une part, copier le bitmap par draw de manière à le faire apparaître tel quel et d'autre part, recopier ce bitmap par StretchDraw en augmentant ses coordonnées, on ajoute chaque fois la variable aug initialisée à 20. Vous constaterez que le bitmap grandit à chaque click.

Pour réaliser ce test, il suffit donc de poser un bouton sur Form1 (de préférence vers le haut sur la droite car l'affichage à lieu vers la gauche dans ce petit exemple) et de copier-coller le code suivant dans l'unité cpp associée.

#include <vcl.h>
#pragma hdrstop

#include "Unit10.h"
//------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
Graphics::TBitmap *Bmp;
int aug=20;
TRect R;
//---------------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
Bmp=new Graphics::TBitmap();
Bmp->Height=50;
Bmp->Width=50;
Bmp->Monochrome=true;
Bmp->Canvas->TextOutA(10,10,"Essai");

R.left=120;
R.top=20;
R.right=R.left;
R.bottom=R.top;
}
//---------------------------------------------------------
void __fastcall TForm1::FormDestroy(TObject *Sender)
{
delete Bmp;
}
//---------------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
R.right+=aug;
R.bottom+=aug;
Form1->FormPaint(Sender);
}
//----------------------------------------------------------
void __fastcall TForm1::FormPaint(TObject *Sender)
{
Form1->Canvas->Draw(20,20,Bmp);
Form1->Canvas->StretchDraw(R,Bmp);
}

Remarquez que la méthode Button1Click appelle FormPaint. Ce petit programme ne fonctionnera pas immédiatement suite à ce copier-coller car les méthodes Button1Click et FormPaint ne font encore pas partie de la classe TForm1 puisqu'on est supposé partir d'une application vierge. Pour que le programme fonctionne, il faut double-cliquer sur l'événement OnClick de Bouton1 (pour que C++Builder crée le gestionnaire) et idem sur l'événement OnPaint de Form1 puis vous effacez immédiatement ces deux gestionnaires dans le cpp (ou même à la limite vous ne faites rien, ces deux gestionnaires disparaîtront d'eux-mêmes à la prochaine compilation puisqu'ils sont vides, par exemple faites alt-F9 pour compiler uniquement l'unité, les deux gestionnaires créés disparaissent). En effet, le but n'est pas d'utiliser ces gestionnaires (car ils existent déjà dans le source copié-collé) mais de déclarer ces deux méthodes dans la classe TForm1 situées dans unitxx.h. D'ailleurs, si vous faites Ctrl-F6 (contrôle F6) pour consulter le source en-tête, vous constatez que les deux méthodes Button1Click et FormPaint ont bien été insérées dans la classe TForm1.