Discussion :

[ovni76]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Invité]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[ovni76]

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

[Invité]

Bonjour,

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

Pas mieux ... 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[ovni76]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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+