Discussion :

[bvsud]

Bonjour à tous

Décidément ça rentre pas !!

J'ai un TEdit sur lequel fixer le focus tant qu'on n'en est pas sorti pas RETURN ou ESCAPE. Je gère les touches, ok. Mais mon prog passe à l'instruction suivant l'appel de la saisie sans s'y arrêter !!

J'ai fait un petit exemple ici :

Procéduire appelant la saisie :

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
 
procedure Ouverture;
begin
        Handle_App := Application.Handle;
        Date_Der_Modif := '27-03-2011'; 
        Form1.Caption := Date_Der_Modif;
 
        Initialiser_Variables;
 
        Saisie_Chn;
        if Saisie_Terminee = True then
            begin
                  MessageDlg('Passage après saisie', mtInformation, [mbOK], 0);
            end
        else Form1.Edit1.SetFocus;
 
        Quitter;
end;

Procédure de saisie :

Code :

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

1
2
3
4
5
6
7
8
9

Procedure Saisie_Chn;
begin
      Saisie_Terminee := False;
      Form1.Edit1.Text := Txt_Initial;  // Ou n'importe quoi d'autre
      Form1.Edit1.SetFocus;  // N'attend pas la saisie des touches ds le TEdit !!

end;

Je gère les touches avec l'événement OnKeyDown du TEdit. Où dois-je placer Application.ProcessMessage ??

Merci

P.S.: je raisonne tjrs en procédural... J'ai des procédures programmant plusieurs choses, et lorsque je dois stopper le prog sur un TEdit, vlan !

Je rajoute la procedure traitant l'entrée des touches :

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
 
 
Procedure Traiter_Touche;
begin
 
      CASE Touche OF
 
          vk_ESCAPE :
                begin
                    Saisie_Terminee := True;
                    Form1.Edit1.Text := Txt_Initial;
                    Chn_Saisie := '';
                    Form1.Edit1.Enabled := False;
                    Form1.Btn_Quitter.SetFocus;
              end;
 
          vk_RETURN :
              begin
                    Saisie_Terminee := True;
                    Chn_Saisie := Form1.Edit1.Text;
                    Form1.Edit1.Enabled := False;
                    Form1.StatusBar1.SimpleText := Chn_Saisie;
                    Form1.Btn_Quitter.SetFocus;
              end;
 
          vk_F1 :
              begin
                    Touche := 0; 
                    MessageDlg('Touche interdite !', mtWarning, [mbOK], 0);
                    Form1.Edit1.SetFocus;
              end;
 
           else
              begin
                    Touche := 0; 
                    Form1.Edit1.SetFocus;
              end;                     
 
      end;  // Case
 
 
end;

[skywaukers]

Bonjour,

je pense que tu ne prends pas le problème par le bon côté. SetFocus met le focus sur le composant, c'est à dire que c'est lui qui est actif, mais en aucun cas il ne bloque l'application.
Pour faire ce que tu veux faire, il faut regarder du côté des évènements. Regarde dans l'inspecteur d'objets (onglets evennements) pour le TEdit en question. Tu dois avoir un event "OnExit", double click dessus pour créer la méthode et place dedans le code que tu souhaite exécuter lorsque l'utilisateur sortira de ce champs.

@++
Dany

[bvsud]

Bonjour,

je pense que tu ne prends pas le problème par le bon côté. SetFocus met le focus sur le composant, c'est à dire que c'est lui qui est actif, mais en aucun cas il ne bloque l'application.
Pour faire ce que tu veux faire, il faut regarder du côté des évènements. Regarde dans l'inspecteur d'objets (onglets evennements) pour le TEdit en question. Tu dois avoir un event "OnExit", double click dessus pour créer la méthode et place dedans le code que tu souhaite exécuter lorsque l'utilisateur sortira de ce champs.

@++
Dany

Merci.

Mais ça ne change rien

Code :

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

1
2
3
4
5
 
procedure TForm2.JvEdit1Exit(Sender: TObject);
begin
      Traiter_Touche;
end;

Le prog passe à ce qui suit le TEdit, et il ne se passe rien...

[Paul TOTH]

ce n'est tout simplement pas comme cela que fonctionne une application Windows.

une application Windows est une boucle sans fin de traitement de messages.

sans cette boucle rien ne fonctionne, et c'est cette boucle qui déclenchera les différents évènements.

Pour lancer cette boucle sous Delphi il suffit d'appeler Application.Run (ce qui est fait par défaut sur un nouveau projet dans le .DPR).

la condition de sortie de cette boucle est la fin de l'application, d'où le code par défaut d'une application :

Code :

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

1
2
3
4
5
6
 
begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

[skywaukers]

Merci.

Mais ça ne change rien

Code :

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

1
2
3
4
5
 
procedure TForm2.JvEdit1Exit(Sender: TObject);
begin
      Traiter_Touche;
end;

Le prog passe à ce qui suit le TEdit, et il ne se passe rien...

Oui, le code ne s'arrêtera jamais, comme l'a dit Paul Toth une application windows est une boucle sans fin qui traite des messages. Il faut repenser ton programme en évènementiel, il n'y a pas d'autre moyen. Le seul endroit où tu peut dire que l'utilisateur a finit sa saisie, c'est dans l'event OnExit de ton TEdit car cet event est provoqué lorsque l'utilisateur quitte le contrôle (qu'il ait saisit quelque chose ou non par contre).

@++
Dany

[bvsud]

Oui, le code ne s'arrêtera jamais, comme l'a dit Paul Toth une application windows est une boucle sans fin qui traite des messages. Il faut repenser ton programme en évènementiel, il n'y a pas d'autre moyen. Le seul endroit où tu peut dire que l'utilisateur a finit sa saisie, c'est dans l'event OnExit de ton TEdit car cet event est provoqué lorsque l'utilisateur quitte le contrôle (qu'il ait saisit quelque chose ou non par contre).

@++
Dany

Bon. Mais lorsque je réponds à OnExit par un retour de focus sur le TEdit, pour attendre la saisie sot de 13 (return) soit de 27 (escape), le prog continue. C'est quelque par par là qu'il faut placer Application.ProcessMessage, je suppose ?

C'est tjrs les trucs comme ça qui me mettent dedans !

Bref : il y a un tuto quelque part pour forcer une saisie ds un TEdit ?

Je gère bien les saisies ds les ListBox (là, aucun pb), mais les TEdit.... Or, la procédure "Pilote" qui appelle les différentes sous-procédures, à un moment précis, a besoin de cette saisie.

Je ne sais pas si je me fais bien comprendre...

[Paul TOTH]

non tu ne te fais pas comprend et tu n'as pas compris ma réponse.

il n'y a pas à appeler ProcessMessages, c'est Application.Run qui s'en charge.

la programmation sous Windows n'est pas procédurale, elle est évènementielle.

enfin si tu peux faire du procédural en application Console

Code :

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

1
2
3
4
5
6
7
8
9
10
 
program Demo;
{$APPTYPE CONSOLE}
var
  s: string;
begin
 ReadLn(s);
 if s = '...' then
   ...
end;

dans une application graphique cette notion n'existe pas, tu as plusieurs points d'entrée qui correspondent à chaque fois à un évènement "OnXXX"

OnKeyPress, OnExit, OnClick...OnIdle (pas d'évènement)

et l'ordre de ces évènements n'est pas déterminé par le programme mais par les évènements (clavier, timer, connexion...) donc dans un ordre non prévisible.

[bvsud]

non tu ne te fais pas comprend et tu n'as pas compris ma réponse.

il n'y a pas à appeler ProcessMessages, c'est Application.Run qui s'en charge.

la programmation sous Windows n'est pas procédurale, elle est évènementielle.

enfin si tu peux faire du procédural en application Console

Code :

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

1
2
3
4
5
6
7
8
9
10
 
program Demo;
{$APPTYPE CONSOLE}
var
  s: string;
begin
 ReadLn(s);
 if s = '...' then
   ...
end;

dans une application graphique cette notion n'existe pas, tu as plusieurs points d'entrée qui correspondent à chaque fois à un évènement "OnXXX"

OnKeyPress, OnExit, OnClick...OnIdle (pas d'évènement)

et l'ordre de ces évènements n'est pas déterminé par le programme mais par les évènements (clavier, timer, connexion...) donc dans un ordre non prévisible.

D'accord Mais alors pourquoi le prog ne réagit-il pas à l'événement OnExit du TEdit , alors que les ListBox par exemple ne me posent pas de pb particulier ? Il y a forcément une instruction à écrire pour répondre à ces deux évènements :

- saisie de la touche ENTREE
- saisie de la touche ESCAPE

Ca marche partout sauf sur les TEdit...

[skywaukers]

Bon. Mais lorsque je réponds à OnExit par un retour de focus sur le TEdit, pour attendre la saisie sot de 13 (return) soit de 27 (escape), le prog continue. C'est quelque par par là qu'il faut placer Application.ProcessMessage, je suppose ?

C'est tjrs les trucs comme ça qui me mettent dedans !

Bref : il y a un tuto quelque part pour forcer une saisie ds un TEdit ?

Je gère bien les saisies ds les ListBox (là, aucun pb), mais les TEdit.... Or, la procédure "Pilote" qui appelle les différentes sous-procédures, à un moment précis, a besoin de cette saisie.

Je ne sais pas si je me fais bien comprendre...

Je pense que tu devrais expliquer exactement ce que tu veux faire car à mon avis on ne comprend pas ton besoin.
si dans le onexit tu met un Edit1.setFocus, alors le curseur doit se trouver dans le Edit1.
Maintenant si tu veux faire une action lorsque l'utilisateur frappe sur 13 ou 27, il faut l'intercepter dans l'event onkeydown

Le code ci-dessous met le focus sur edt1, et passe à edt2 uniquement quand l'utilisateur appui sur 13 :

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
unit Unit1;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;
 
type
  TForm1 = class(TForm)
    edt1: TEdit;
    edt2: TEdit;
    procedure edt1Exit(Sender: TObject);
    procedure edt1KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
procedure TForm1.edt1Exit(Sender: TObject);
begin
  edt1.SetFocus;
end;
 
procedure TForm1.edt1KeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
begin
  case Key of
    13 : begin
           ShowMessage( 'Return');
           edt1.OnExit := nil; //<-- sinon la ligne suivante n'a pas d'éffet
                               //    car le Onexit ramenera le focus sur edt1
           edt2.SetFocus;
         end;
    27 : ShowMessage( 'Escape');
  end;
end;

L'idée de la programmation windows c'est que le programme ne dirige pas l'utilisateur, il répond aux actions de l'utilisateur. Donc tu ne va pas bloquer le programme dans l'attente de la saisie dans la zone Edit1, mais par contre tu vas intercepter l'action de fin de saisie dans l’événement OnExit de Edit1, et c'est la que ton programme doit réagir à ce qu'a saisit l'utilisateur. Après tu peux agir plus tôt grâce au OnKeyDown qui te permet d’intercepter toute les touches saisies par l’utilisateur.

@++
Dany

[bvsud]

Je pense que tu devrais expliquer exactement ce que tu veux faire car à mon avis on ne comprend pas ton besoin.
si dans le onexit tu met un Edit1.setFocus, alors le curseur doit se trouver dans le Edit1.
Maintenant si tu veux faire une action lorsque l'utilisateur frappe sur 13 ou 27, il faut l'intercepter dans l'event onkeydown

Le code ci-dessous met le focus sur edt1, et passe à edt2 uniquement quand l'utilisateur appui sur 13 :

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
unit Unit1;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;
 
type
  TForm1 = class(TForm)
    edt1: TEdit;
    edt2: TEdit;
    procedure edt1Exit(Sender: TObject);
    procedure edt1KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
procedure TForm1.edt1Exit(Sender: TObject);
begin
  edt1.SetFocus;
end;
 
procedure TForm1.edt1KeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
begin
  case Key of
    13 : begin
           ShowMessage( 'Return');
           edt1.OnExit := nil; //<-- sinon la ligne suivante n'a pas d'éffet
                               //    car le Onexit ramenera le focus sur edt1
           edt2.SetFocus;
         end;
    27 : ShowMessage( 'Escape');
  end;
end;

L'idée de la programmation windows c'est que le programme ne dirige pas l'utilisateur, il répond aux actions de l'utilisateur. Donc tu ne va pas bloquer le programme dans l'attente de la saisie dans la zone Edit1, mais par contre tu vas intercepter l'action de fin de saisie dans l’événement OnExit de Edit1, et c'est la que ton programme doit réagir à ce qu'a saisit l'utilisateur. Après tu peux agir plus tôt grâce au OnKeyDown qui te permet d’intercepter toute les touches saisies par l’utilisateur.

@++
Dany

OK. Ton exemple fonctionne, et je comprends pourquoi. Il n'y a aucune fonction appelée ensuite. Donc, on reste "bloqué" sur le TEdit.

Maintenant, voici l'organigramme de ma procédure pilote de ce bloc de programme utilisant un TEdit :



Il y a une suite ! Comme ici : (simple exemple fait pour ce post)

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
 
procedure Ouverture;  // Réponse à l'évènement Onctivate de la Form 
begin
 
        // Entrée de prog habituelle chez moi
        Handle_App := Application.Handle;
        Date_Der_Modif := '28-03-2011';
        Form1.Caption := Date_Der_Modif;
 
        Initialiser_Variables;
 
        // Instruction 1 : la saisie, et ça fonctionne SI AUCUNE INSTRUCTION APRES !
        Form1.Edit1.SetFocus;
 
        // Instruction 2, etc...
        //Quitter;  <<----------- C'est là que ça dérape. La suite du prog ne 
                          LAISSE PAS le focus sur le TEdit. Elle va jusqu'au bout !
 
 
end;

Est-ce que je fais mieux comprendre ? Voilà pourquoi, en cas de TEdit, j'ai si souvent recours à un CreateProces() : le processus fils ne fait QUE l'opération de saisie ds le TEdit.

On ne peut pas éviter ça ? Càd inclure un TEdit dans une succession d'appels de procédures ?

[Paul TOTH]

...
Est-ce que je fais mieux comprendre ? Voilà pourquoi, en cas de TEdit, j'ai si souvent recours à un CreateProces() : le processus fils ne fait QUE l'opération de saisie ds le TEdit.

On ne peut pas éviter ça ? Càd inclure un TEdit dans une succession d'appels de procédures ?

Non je ne comprend strictement rien à ta façon de coder les choses.

donne un exemple complet du code (comme l'a fai Skywaukers) car tes portions de code qui ne contiennent que des procédure non-objet sont incompréhensibles.

[skywaukers]

OK. Ton exemple fonctionne, et je comprends pourquoi. Il n'y a aucune fonction appelée ensuite. Donc, on reste "bloqué" sur le TEdit.

Mais bien sûr, excuse moi d’insister, mais SetFocus ne fait que positionner le curseur dans le TEdit, en aucun cas il n'arrête pour attendre la saisie de l'utilisateur.

Pour moi ce que tu fais dans le OnKeyDown est correct, il faut que tu appelles la suite du traitement à ce moment là (ou que tu fasse un Setfocus pour empêcher l'utilisateur de quitter l'Edit). En gros pour en référer à ton exemple tu appelle Quitter sur vk_Return et vk_Escape, sinon setFocus (comme c'est déjà le cas). Ainsi tu n'as plus de code après SaisieChn.

@++
Dany

[Jipété]

Et si tu veux absolument bloquer ton programme, tiens, teste ce petit machin de démo (un bouton sur une form, et c'est tout) :

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
var
  saisie_valide: boolean;
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  Show; // obligatoire sinon rien d'affiché !
  while not saisie_valide do // prog bloqué
  begin
    Application.ProcessMessages; // pour que
    // le clic sur le bouton soit pris en compte
  end;
  Form1.Color := clRed; // suite du prog...
end;
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  saisie_valide := True;
end;

[ShaiLeTroll]

bvsud, tu devrais peut-être découpé tes ecrans en de très petite partie, si tu veux guider la saisie !

Regarde ShowModal pour afficher une Form et attendre que l'on valide (ModalResult ou TButton)

Sinon, InputQuery\InputBox pour affiche un Edit (+ Libelle), ça sera le plus ressemblant à ton désir de programmation bloquante (hérétique ?)

la technique de Jipété, risque de solliciter le CPU à 100% (pour un des CPU si multi) !
Sleep réduira cet effet, un délai de 50ms ne se verra pas !

Tu pourrais aussi jouer avec Enabled, seul un control est à true, le reste est à false, une fois la saisie faite, tu bascule le enabled sur le control suivant (délirant ???)

Regarde aussi TabStop et TabOrder, c'est ce que réclame le plus les utilisateurs qui doivent saisir en masse, pour ne jamais toucher la souris et tout faire au clavier (comme sous AS4000 ou DOS), la touche TAB, ENTER passe au champ suivant jusqu'a Bouton !


bvsud, dans quel cadre développes-tu ce projet ?
ça me rappele ce sujet Créer un jeu d'aventure textuel avec un déroulement de l'interface utilisateur step by step !

Peut-être que l'on pourrait te proposer un process différent !