Séquence d'événements des Form sous Windows

Bonjour,
Je développe habituellement sous linux fedora 16 actuellement et pour un membre de ma famille je souhaite lui fournir une petite application de gestion de données qui tourne bien sous linux avec les composants natifs sqlite3 et bien l'opération ne s'avère pas simple.
Dans les 2 environnements j'utilise la version 1.0 de lazarus.
Mon principal problème se trouve avec les événements de TForm.
J'ai une form principale et via avec actions sur des boutons (je préfére les boutons au système de menu) j'ouvre une autre fenêtre par une action FormX.Show.
Sous linux en arrivant dans cette nouvelle fiche souvant je change "l'affichage" d'une table en ajoutantun filtre ou l'ordre, voir ci-dessous

Code:

---

1 2 3 4 5

data.bank.Close; data.bank.SQL:='select * from BANK order by CODEDATE'; data.bank.open; data.bank.ExecSQL; data.bank.Last;

---

Sous linux j'écris cette action dans un événement On Activate sans problème mais sous windows ça ne fonctionne pas j'ai essayé avec l'événement OnShow mais il me répond qui ne peut pas fermer ma table .... pourtant si je mets dans ma fiche un DBGrid associé à ma table il la voit bien donc la table est reconnue alors pourquoi ce refus, pourquoi cette différence dans l'utilisation des événements entre linux et windows et où puis-je trouver l'usage des événements liés àTform en français si possible.
Merci d'avance

Bonsoir,

Dans tous les environnements, je préfère overrider le Update de la Form comme on en a déjà parlé. C'est la seule solution qui m'a permis d'obtenir facilement un comportement similaire. Sinon, il faut repérer dans chaque Form la séquence d'appel des évènements suivant l'OS et placer les méthodes en dehors des Onxxxx et les permuter si la séquence des appels est inversée d'un environnement à l'autre.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Method1 Method2   -->OnShow {$IFDEF windows} Method1() {$ENDIF} {$IFDEF linux} Method1() {$ENDIF}   -->OnActivate {$IFDEF windows} Method2() {$ENDIF} {$IFDEF linux} Method1() {$ENDIF}

---

J'y ai renoncé. Le Update se déclenche à la main... donc quand on veut ou presque :

Code:

---

1 2 3 4 5

With Form2 do begin Show; Update; end;

---

C'est ce que j'ai trouvé de plus simple.
Petite remarque : j'ai eu des problèmes également de ce type entre un windows XP et un Seven...

Cordialement. Gilles

Merci Gilles mais ayant réussi à contourner mon problème à l'époque et surtout étant dépassé par la proposition, je ne suis qu'un petit bidouilleur, un peu plus d'explications voire un exemple me seraient fort utiles.
Merci d'avance

Bonjour,

Citation:

---

Envoyé par ovni76

[...]je ne suis qu'un petit bidouilleur

---

Pas mieux :aie:... mais cela me convient bien : cela limite la "pression" et laisse ouverte toutes les options.

Pour en revenir au problème évoqué, il faudrait réduire les hypothèses. Vous ouvrez la seconde Form à partir de la première en utilisant un TButton.

Je suppose que la Form2 n'est pas défini dans le project1.lpr

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

program project1;   {$mode objfpc}{$H+}   uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Interfaces, // this includes the LCL widgetset Forms, Unit1 { you can add units after this };   {$R *.res}   begin RequireDerivedFormResource := True; Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end.

---

On considérera donc que la Form2 est construite à partir de Form1. Ensuite, il faut voir ce que vous voulez. Un close ne signifie pas la destruction de la Form. Autrement dit,

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

procedure TForm1.Button1Click(Sender: TObject); begin { Uses unit2;} Application.CreateForm(TForm2, Form2); with Form2 do begin Show; Sleep(2500); Close; Showmessage(''); Show; Sleep(2500); Close; end; end;

---

fait apparaître 2 fois la Form2. Mais la méthode CreateForm n'est appelée qu'une fois... ce qui change par exemple la séquence des évènements si on une utilise une autre variante d'appel et de fermeture des fenêtres.

Car les variantes sont nombreuses. On peut mélanger les Form qui se recréent pour chaque Show (après libération à la fermeture) et les Form que l'on "Close" sans libération ou que l'on Hide. Je ne sais pas si c'est particulier à Lazarus dans la mesure où mes projets Delphi sont beaucoup moins "élaborés" que ceux en Lazarus. On trouve des posts sur le sujet en Delphi et il semble que l'on y affirme que le Close entraine le release et la "désassignation". En Lazarus, l'exemple ci-dessus démontre le contraire. Le 1er close entrainerait le plantage du 2nd show s' il y avait désassignation.

Si vous voulez automatiser la destruction de la Form2 :

• de l'intérieur :

Code:

---

1 2 3 4 5

procedure TForm2.FormClose(Sender: TObject; var CloseAction: TCloseAction); begin CloseAction := caFree; Form2 := nil; {Pour libérer et pouvoir utiliser le if assigned(Form2) } end;

---

• ou à partir d'un Tbutton de Form1

Code:

---

1 2 3 4 5 6 7 8 9

procedure TForm1.Button2Click(Sender: TObject); begin if assigned(Form2) then begin with Form2 do Close; Form2 := nil; {Pour libérer et pouvoir utiliser le if assigned(Form2) } Showmessage('Form2.Destroy'); end; end;

---

mais attention, à chaque référence à Form2 à partir d'une autre fenêtre

Code:

---

1 2 3

if not Assigned(Form2) then Application.CreateForm(TForm2, Form2); {--> Obligatoire si désassignée} Form2.Show;

---

Donc en résumé, la séquence des évènements dépend de la méthode d'appel (je ne parle pas de la différenciation Showmodal/Show) et malheureusement aussi de l'OS.

Supposons qu'à l'ouverture de la Form2 sur laquelle je pose un Label1 je passe ce code qui simule un "ralentissement" causé par exemple par un accès à une BDD :

Code:

---

1 2 3 4 5

procedure TForm2.AfficherLabel(); begin Sleep(4500); Label1.Color := clRed; end;

---

Si je crée la Form2 à partir du bouton dans la Form1,

Code:

---

1 2 3 4 5 6 7 8 9

procedure TForm1.Button1Click(Sender: TObject); begin if not Assigned(Form2) then begin Application.CreateForm(TForm2, Form2); Showmessage('Recréé'); {Ici pour faire apparaître la latence} end; Form2.show; end;

---

pendant 4 seconde la Form2 n'apparait pas, puis au bout de ce laps de temps elle apparait. Ce qui fait que pendant 4 secondes, "on" a l'impression d'un freeze puisque le clic ne semble rien déclencher.

J'utilise la procédure suivante dans la Form2 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

TForm2 = class(TForm) procedure FormClose(Sender: TObject; var CloseAction: TCloseAction); procedure FormCreate(Sender: TObject); procedure FormShow(Sender: TObject); private { private declarations } procedure Update; override; public { public declarations } procedure AfficherLabel(); end; [...] procedure TForm2.Update; begin inherited; AfficherLabel(); end;   procedure TForm2.AfficherLabel(); begin Sleep(4500); Label1.Color := clRed; end;   procedure TForm2.FormClose(Sender: TObject; var CloseAction: TCloseAction); begin CloseAction := caFree; Form2 := nil; end;

---

et la procédure d'appel de TForm1

Code:

---

1 2 3 4 5 6 7 8 9

procedure TForm1.Button1Click(Sender: TObject); begin if not Assigned(Form2) then Application.CreateForm(TForm2, Form2); with Form2 do begin Show; Update; end; end;

---

Le clic sur le bouton de la Form1 laisse dessiner immédiatement la Form2 (avec les messages que l'on veut dedans, une animation, un sablier, un dbGrid pratiquement immédiatement visible rempli au moins partiellement si le TConnector accepte le FetchRow...).
Voila.

Je remets tous les codes de l'exemple final

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142

program project1;   {$mode objfpc}{$H+}   uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Interfaces, // this includes the LCL widgetset Forms, Unit1 { you can add units after this };   {$R *.res}   begin RequireDerivedFormResource := True; Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end.   unit Unit1;   {$mode objfpc}{$H+}   interface   uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls, unit2;   type   { TForm1 }   TForm1 = class(TForm) Button1: TButton; Button2: TButton; procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); private { private declarations } public { public declarations } end;   var Form1: TForm1;   implementation   {$R *.lfm}   { TForm1 }   procedure TForm1.Button1Click(Sender: TObject); begin if not Assigned(Form2) then Application.CreateForm(TForm2, Form2); with Form2 do begin Show; Update; end; end;   procedure TForm1.Button2Click(Sender: TObject); begin if assigned(Form2) then begin with Form2 do Close; Form2 := nil; Showmessage('Form2.Destroy'); end; end;   end.   unit unit2;   {$mode objfpc}{$H+}   interface   uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;   type   { TForm2 }   TForm2 = class(TForm) Button1: TButton; Label1: TLabel; procedure Button1Click(Sender: TObject); procedure FormClose(Sender: TObject; var CloseAction: TCloseAction); procedure FormShow(Sender: TObject); private { private declarations } procedure Update; override; public { public declarations } procedure AfficherLabel(); end;   var Form2: TForm2;   implementation   {$R *.lfm}   { TForm2 }   procedure TForm2.Update; begin inherited; AfficherLabel(); end;   procedure TForm2.AfficherLabel(); begin Sleep(4500); Label1.Color := clRed; end;   procedure TForm2.Button1Click(Sender: TObject); begin Close; end;   procedure TForm2.FormClose(Sender: TObject; var CloseAction: TCloseAction); begin CloseAction := caFree; Form2 := nil; end;   procedure TForm2.FormShow(Sender: TObject); begin //AfficherLabel(); {Non car pas update} end;     end.

---

J'espère que cela répond un peu à votre question.
Cordialement. Gilles

Bonsoir Gilles,
J'ai débuté dans la programmation avec le langage de Dbase III+ puis la version 4 avec une fenêtre principale et des "boutons" appelant d'autres fenêtres pour des séquences spécialisées.
En passant ensuite sous delphi 4 j'ai utilisé le même principe et il en est de même sous lazarus. Petite précision toutes mes applications gérent des données avant avec des fichiers dbase et depuis 2 ou 3 ans je me suis converti à sqlite avec les composants natifs.
Donc dans mes applications simples, je crée un projet, une fiche principale avec dans un panel spécifique les boutons permettant l'appel aux fiches spécialisées.
Ces fiches peuvent dans certains cas permettre l'appel d'autres fiches dans la spécialisation de la précédente un exemple : dans une application de gestion des dépense de véhicules la fiche principale permet d'ouvrir une fiche de création des dépenses mais aussi de consulter les dépenses, de consulter les fiches véhicules, de créer une nouvelle fiche véhicule etc...
Donc dans mon nouveau projet j'ai une première fiche créée automatique avec le projet c'est pour moi la principale, ensuite je crée une fiche datamodule sur laquelle je crée mes accès aux tables de ma base et les datasource correspondants ensuite j'ajoute une unité spécifique avec des procédures que j'utilise souvent comme la mise en forme de donnée :issue d'un maskedit en supprimant les espaces dans une donnée avec décimales,de rajouter des zéros pour avoir le nombre de décimales voulues à un nombre, etc...
Ensuite je crée mes fiches pour les actions spécialisées et après chaque création j'ajoute la nouvelle fiche au projet ci-joint un exemple de projet sous linux

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

program pslcl; // nouveau projet sqlazlcl du 04 février 2011 vers 14h00   {$mode objfpc}{$H+}   uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Interfaces, // this includes the LCL widgetset Forms, uslcl, udata, uoutils, ureorganiser, ucorriger, utransfert, uservice, urecherche, uconsulter, uautomat, uarchiver, upointer, uentrer, uimporter;   {$R pslcl.res}   begin Application.Initialize; Application.CreateForm(TFslcl, Fslcl); Application.CreateForm(TData, Data); Application.CreateForm(TFreorganiser, Freorganiser); Application.CreateForm(TFcorriger, Fcorriger); Application.CreateForm(TFtransfert, Ftransfert); Application.CreateForm(TFservice, Fservice); Application.CreateForm(TFrecherche, Frecherche); Application.CreateForm(TFconsulter, Fconsulter); Application.CreateForm(TFautomat, Fautomat); Application.CreateForm(TFarchiver, Farchiver); Application.CreateForm(TFpointer, Fpointer); Application.CreateForm(TFentrer, Fentrer); Application.CreateForm(TFimporter, Fimporter); Application.Run; end.

---

ces fiches sont appelées par le click sur un bouton et lance un appel Form.Show;
et je quitte la fiche par un bouton qui réinitialise les composants de la fiche dans leur état de départ et une commande close.
Quand j'arrive dans une fiche j'utilise souvent une table et cette table sera peut-être ouverte avec une commande diférente de celle réalisée dans la fiche datamodule par exemple avec un filtre ou un ordre différent.
Sous linux je réalise cette opération avec l'événement OnActivate sans difficulté, sous windows XP ça ne fonctionne pas, je contourne le problème en réalisant l'opération au moment du choix de l'action dans cette fiche.
Mais j'ai l'habitude d'organiser les applications en créant un répertoire ayant un nom es relation avec le projet et le projet et les différentes unité et fiches sont dans un sous répertoire source et ma base dans un répertoire tables mais il y a aussi 6 autres sous répertoire de sauvegarde tablesA à tablesF. Pourquoi, toujours une veille habitude de sauvegarder mes données, avant sur disquette avecgestion des disquettes par rotation avec un changement de nom. Maintenant je le fait en copiant la base de travail dans un répertoire A à F selon une donnée dans une table, donnée qui change à chaque sortie de mon application si une table a été modifiée.
Pour cela sous linux l'événement OnActivate de la fiche principale va lire dans une table de "service" les données pour la prochaine sauvegarde voir l'exemple ci-joint

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

procedure TFslcl.FormCreate(Sender: TObject); begin // préparation de l'environnement defaultFormatSettings.ShortDateFormat:='DD/MM/YYYY'; defaultFormatSettings.DateSeparator:='/'; defaultFormatSettings.DecimalSeparator:=','; end;   procedure TFslcl.FormActivate(Sender: TObject); begin FutureSauvegarde; end;   procedure TFslcl.FutureSauvegarde; begin MSAUVE_A:=data.divers.FieldByName('SAUVE_A').AsString; MSAUVE_B:=data.divers.FieldByName('SAUVE_B').AsString; MSAUVE_C:=data.divers.FieldByName('SAUVE_C').AsString; MSAUVE_D:=data.divers.FieldByName('SAUVE_D').AsString; MSAUVE_E:=data.divers.FieldByName('SAUVE_E').AsString; MSAUVE_F:=data.divers.FieldByName('SAUVE_F').AsString; MSAUVE_X:=data.divers.FieldByName('SAUVE_X').AsString; XSAUVE_X:=StrToInt(MSAUVE_X); Case XSAUVE_X of 1: begin MDESTINATION:='tablesA/'; MSAUVE_X:='2'; end; 2: begin MDESTINATION:='tablesB/'; MSAUVE_X:='3'; end; 3: begin MDESTINATION:='tablesC/'; MSAUVE_X:='4'; end; 4: begin MDESTINATION:='tablesD/'; MSAUVE_X:='5'; end; 5: begin MDESTINATION:='tablesE/'; MSAUVE_X:='6'; end; 6: begin MDESTINATION:='tablesF/'; MSAUVE_X:='1'; end; end; Edit2.Text:=MDESTINATION; Edit2.Update; end;

---

et pour la sauvegarde je teste une variable comme ci-dessous

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

procedure TFslcl.BQuitterClick(Sender: TObject); begin if MMODIFICATION='OUI' then begin Q1:=quotedstr(MSAUVE_X); MQ:='update divers set SAUVE_X='+Q1+' where K_DIVERS=1'; data.divers.SQL:=MQ; data.divers.ExecSQL; data.divers.ApplyUpdates; Edit2.Text:=MDESTINATION; Edit2.Update; MCHEMIN:=data.divers.FieldByName('REPERTOIRE').AsString; MBASE:='LCL.sdb'; MSOURCE:=MCHEMIN+'tables/'+MBASE; MDESTINATION:=MCHEMIN+MDESTINATION+MBASE; CopierFichier (MSOURCE,MDESTINATION); BQuitter.Enabled:=False; BFermer.Visible:=True; end else Close; end;

---

Sous windows l'événement OnActivate réagit d'une manière différente et quand j'arrive dans FutureSauvegarde il ne trouve pas "le chemin" de data.divers.
Pour avancer je triche en suppimant cet événement et en ajoutant un nouveau bouton "Acivation de l'application" visible seulement au lancement de l'application et qui lance la procédure FutureSauvegarde.
Tout cela est sur simpliste mais à mon age ....
J'ai l'impression que par le passé avec les versions 0.9.30 le passage d'applications écrites sous linux ne posaient pas tous ces problèmes sous windows.
J'espère ne pas avoir été trop brouillon dans mon récit.
A+