[BPW]Problème de recherche dans une boîte liste

**Alcatîz** · 15/06/2003, 20h59

Bonjour à tous et toutes !

Dans une boîte de dialogue Windows, je suis amené à implémenter un petit accessoire de recherche dans une boîte liste qui contient (notamment) des noms de personnes.

Le principe est le suivant : lorsque l'on tape le début du nom d'une personne, la boîte liste sélectionne celle-ci automatiquement.
Toute lettre tapée s'ajoute à une chaîne de recherche et toute autre touche réinitialise la chaîne de recherche.

Tout fonctionne bien sauf que, après que mon programme ait sélectionné la bonne personne, Windows ramène la sélection immédiatement au 1er nom de la liste.

Malgré l'usage intensif du debugger, je ne trouve pas ce qui provoque cette réaction de Windows.
Plus fort encore : lorsque, dans un but de test, j'affiche une petite boîte à messages pour faire apparaître la chaîne de recherche dans son état actuel, Windows ne déplace plus la sélection ! J'y perds mon latin.

Quelques informations sur la boîte liste : elle a les attributs lbs_OwnerDrawFixed (éléments dessinés par le programme et non par Windows), lbs_Sorted (routine de tri fournie par le programme), lbs_WantKeyboardInput (renvoi des caractères tapés au programme) mais pas lbs_HasStrings (la boîte liste ne possède que des pointeurs vers des données de mon programme).

Déclaration du dialogue :

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
Type pDlgListePersonnes = ^tDlgListePersonnes;
     tDlgListePersonnes = Object(tDialog)
       hListe : hWnd;                       (* HANDLE DE LA BOITE LISTE *)
       OptionTri : Integer;                 (* METHODE DE TRI  *)
       pTeteAjout : pPersonne;              (* TETE LISTE NOUVEAUX ELEMENTS *)
       pQueueAjout : pPersonne;             (* QUEUE LISTE NOUVEAUX ELEMENTS *)
       Recherche : Array [0..20] of Char;   (* CHAINE A RECHERCHER *)
       Constructor INIT (FenetreParent : pWindowsObject);
          (* CONSTRUCTION DU DIALOGUE
             INITIALISATION DES CHAMPS *)
       Procedure SETUPWINDOW;
          virtual;
          (* CENTRAGE DU DIALOGUE
             INITIALISATION BOITE LISTE DES PERSONNES *)
       Procedure WMMEASUREITEM (var Msg : tMessage);
          virtual wm_First + wm_MeasureItem;
          (* DETERMINATION HAUTEUR D'UNE LIGNE BOITE LISTE *)
       Procedure WMDRAWITEM (var Msg : tMessage);
          virtual wm_First + wm_DrawItem;
          (* DESSIN D'UN ELEMENT DE LA BOITE LISTE *)
       Procedure WMCOMPAREITEM (var Msg : tMessage);
          virtual wm_First + wm_CompareItem;
          (* COMPARAISON DE 2 ELEMENTS BOITE LISTE *)
       Procedure WMCOMMAND (var Msg : tMessage);
          virtual wm_First + wm_Command;
          (* DOUBLE CLIC SUR UN ELEMENT DE LA BOITE LISTE
             CHANGEMENT D'OPTION DE TRI *)
       Procedure WMVKEYTOITEM (var Msg : tMessage);
          virtual wm_First + wm_VKeyToItem;
          (* TOUCHE FRAPPEE AU CLAVIER *)
       Procedure IDAJOUTER (var Msg : tMessage);
          virtual id_First + id_Ajouter;
          (* AJOUT D'UN NOUVEL ELEMENT *)
       Procedure IDMODIFIER (var Msg : tMessage);
          virtual id_First + id_Modifier;
          (* MODIFICATION DE L'ELEMENT COURANT *)
       Procedure IDSUPPRIMER (var Msg : tMessage);
          virtual id_First + id_Supprimer;
          (* SUPPRESSION DES ELEMENTS SELECTIONNES *)
       Procedure OK (var Msg : tMessage);
          virtual id_First + id_OK;
          (* MISE A JOUR DE LA LISTE CHAINEE DES PERSONNES *)
       Procedure CANCEL (var Msg : tMessage);
          virtual id_First + id_Cancel;
          (* MESSAGE DE CONFIRMATION
             DESALLOCATION LISTE NOUVEAUX ELEMENTS *)
     end;

Voici la méthode qui répond à la frappe 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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Procedure tDlgListePersonnes.WMVKEYTOITEM (var Msg : tMessage);
(* TOUCHE FRAPPEE AU CLAVIER *)
Var p : pPersonne;      (* ELEMENT LISTE CHAINEE PERSONNES *)
    Trouve : Boolean;   (* INTERRUPTEUR BOUCLE DE RECHERCHE *)
    Index : Word;       (* INDEX DANS LA BOITE LISTE *)
    Nb : Word;          (* NOMBRE D'ELEMENTS BOITE LISTE *)
Begin
  case Msg.wParam of
    vk_Insert : begin
      IDAJOUTER(Msg);
      (* PAS DE TRAITEMENT ULTERIEUR PAR WINDOWS *)
      Msg.Result:=-2;
      (* REINITIALISATION DE LA CHAINE DE RECHERCHE *)
      FillChar(Recherche,SizeOf(Recherche),0);
    end;
    vk_Return : begin
      IDMODIFIER(Msg);
      (* PAS DE TRAITEMENT ULTERIEUR PAR WINDOWS *)
      Msg.Result:=-2;
      (* REINITIALISATION DE LA CHAINE DE RECHERCHE *)
      FillChar(Recherche,SizeOf(Recherche),0);
    end;
    vk_Delete : begin
      IDSUPPRIMER(Msg);
      (* PAS DE TRAITEMENT ULTERIEUR PAR WINDOWS *)
      Msg.Result:=-2;
      (* REINITIALISATION DE LA CHAINE DE RECHERCHE *)
      FillChar(Recherche,SizeOf(Recherche),0);
    end;
    Ord('A')..Ord('Z') : begin
      if StrLen(Recherche) < (SizeOf(Recherche) - 1)
         then
           begin
             (* AJOUT DANS LA CHAINE DE RECHERCHE *)
             Recherche[StrLen(Recherche)]:=Chr(Msg.wParam);
             (* RECHERCHE DANS LA BOITE LISTE *)
             Nb:=SendDlgItemMessage(hWindow,id_Liste,lb_GetCount,0,0);
             if (Nb <> Word(lb_Err)) and (Nb > 0)
                then
                  begin
                    Index:=0;
                    Trouve:=False;
                    while (Index <= Nb) and not Trouve do
                      begin
                        SendDlgItemMessage(hWindow,id_Liste,lb_GetText,Index,LongInt(@p));
                        if StrLComp(p^.CopieDonnees.NomPersonne,Recherche,StrLen(Recherche)) = 0
                           then
                             Trouve:=True
                           else
                             Inc(Index);
                      end;
                    if Trouve
                       then   (* SELECTION DE L'ELEMENT *)
                         SendDlgItemMessage(hWindow,id_Liste,lb_SetCurSel,Index,0);
                  end;
           end;
      (* PAS DE TRAITEMENT ULTERIEUR PAR WINDOWS *)
      Msg.Result:=-2;
    end;
  else   (* LES AUTRES COMMANDES PEUVENT ETRE TRAITEES PAR WINDOWS *)
    Msg.Result:=-1;
    (* REINITIALISATION DE LA CHAINE DE RECHERCHE *)
    FillChar(Recherche,SizeOf(Recherche),0);
  end;
End;

Merci de m'aider à mettre le doigt sur le "bug" !

**Alcatîz** · 01/07/2003, 12h36

Allo ?

Apparemment, personne n'a l'air plus inspiré que moi (j'ai toujours pas trouvé

).

En attendant, j'ai contourné le problème en créant un petit dialogue où l'on peut inscrire le début du nom à chercher, mais cette solution ne me satisfait pas.

Pour ratisser plus large, j'ai re-posté ma question sur le forum Développement Windows.

**M.Dlb** · 01/07/2003, 13h28

Tout fonctionne bien sauf que, après que mon programme ait sélectionné la bonne personne, Windows ramène la sélection immédiatement au 1er nom de la liste.

Est-ce que tu pourrais être plus clair sur le comportement du programme à cet instant ? Est-ce que windows ramène la sélection après l'appui d'une touche ?
Désolé je ne vois pas de "faille" dans le code... C'est peut-être un bug de Windows ( un bug de la fonction SendDlgItemMessage, je dis ça sous réserve !! )
a+

**Alcatîz** · 01/07/2003, 22h10

Windows retourne au 1er élément immédiatement après avoir surbrillé celui que je sélectionne, sans que l'utilisateur touche à quoi que ce soit.

J'ai placé un break-point sur absolument toutes les méthodes de mon dialogue : aucune n'est exécutée à ce moment. C'est pour cela que j'attribue ce comportement étrange à Windows.

**M.Dlb** · 01/07/2003, 23h45

Vraiment, je ne vois rien dans ce code qui puisse entraîner une erreur...
Sauf, peut-être l'histoire des msg.result:=-2... Je ne connais pas bien la programmation de BPW sous Windows. Est-ce que c'est vous qui avez mis en place le dispositif du msg.result:=-2 pour éviter que le message soit traité par les autres gestionnaires ? ou est-ce une règle made in windows ?
Le problème peut peut-être venir de là, car il se pourrait que windows retraite ce message et alors decide de remettre la sélection sur le premier élément de la liste... Sinon je ne vois pas !!
a+

**Alcatîz** · 02/07/2003, 15h59

J'y ai également pensé et ai même essayé de retourner d'autres valeurs, sans succès...
Le fait d'assigner -2 au résultat d'un message indique à Windows qu'il a été traité et qu'il peut être supprimé de la file des messages.
Mais peut-être que Windows traite encore le message par la suite, malgré tout ?

Ce qui me déroute le plus est que, lorsque j'affiche une MessageBox avec le contenu de la chaîne de recherche, et ce à n'importe quel endroit de la procédure, la surbrillance reste où je veux !

Je doute qu'il s'agisse d'un bug de Windows car le phénomène se produit avec Windows 3.11, Windows NT et Windows 98 (ou alors, ce serait un bug vachement bien ancré, genre famille Bush !

).

Je te remercie énormément d'avoir jeté un coup d'oeil (et même plusieurs, je crois) à mon code !

Bonne prog !

**M.Dlb** · 02/07/2003, 20h57

Ce qui me déroute le plus est que, lorsque j'affiche une MessageBox avec le contenu de la chaîne de recherche, et ce à n'importe quel endroit de la procédure, la surbrillance reste où je veux !

Si la sélection reste après la MessageBox, c'est peut-être bien une erreur de message... Il me semble que windows envoie une série de messages pour afficher une MessageBox ( du genre "affiche toi !!" ), et également la MessageBox possède un gestionnaire d'évènements propre... Si la sélection reste, c'est peut-être parce que justement le dernier message traité n'est pas la sélection ( j'espère que je suis clair

)... Tu devrais peut-être essayer de lancer un message juste après le message de sélection ( un message qui n'aurait pas d'influence sur ton programme )...
Sinon je ne vois vraiment pas, désolé... Il faudrait peut-être qu'un "posteur de message" de la trempe d'HDD34 vienne nous aider !!!!
Bonne chance pour la suite du développement !!
a+

**Alcatîz** · 03/07/2003, 12h49

Envoyé par wormful_sickfoot

Tu devrais peut-être essayer de lancer un message juste après le message de sélection ( un message qui n'aurait pas d'influence sur ton programme )...

Hé mais c'est peut-être une excellente idée !
Je vais creuser cela. Merci !

**Alcatîz** · 03/07/2003, 22h23

J'ai peut-être enfin trouvé le bug ! Plus exactement, je pense qu'il y en a deux : l'un dans mon programme (c'est sûr) et l'autre dans le comportement de Windows (je ne suis pas certain).

La recherche s'effectue dans la méthode de réponse aux messages wm_VKeyToItem.

Théoriquement, la boîte liste ne devrait pas envoyer ce message au dialogue parent, car l'utilisation du style lbs_WantKeyboardInput sans lbs_HasStrings devrait plutôt provoquer l'envoi de messages wm_CharToItem.

Or, wm_VKeyToItem est généré en réponse à un message wm_KeyDown et wm_CharToItem en réponse à un message wm_Char. Mais ces deux messages du système ont une structure absolument identique au niveau de leur paramètre lParam : le bit 31 indique si la touche vient d'être pressée ou si elle vient d'être relâchée.

Je pense donc que mon programme répond aux messages wm_VKeyToItem chaque fois qu'une touche est pressée, mais aussi chaque fois qu'elle est relâchée !

Par exemple, lorsque je presse 'A', mon programme ajoute 'A' à la chaîne de recherche et essaye de trouver cette dernière dans la liste; mais lorsque je relâche la touche, mon programme reçoit un autre code de touche et réinitialise la chaîne de recherche.

Pour résumer :
- 1er bug : mon programme devrait répondre aux messages wm_CharToItem au lieu de wm_VKeyToItem;
- 2è bug : Windows devrait plutôt m'envoyer le bon message, sapristi !

Mon raisonnement tient-il la route ?

**Eric Sigoillot** · 04/07/2003, 00h18

Ton raisonnement me semble plutôt correct !

Il est bien spécifié dans l'aide :

The WM_VKEYTOITEM message is sent by a list box with the LBS_WANTKEYBOARDINPUT style to its owner in response to a WM_KEYDOWN message

Donc, WM_VKEYTOITEM n'est envoyé qu'une seule fois, lors de l'appui d'une touche, et non lors du relâchement.

Par contre, si on regarde l'aide d'un peu plus près (celle de Borland), il est écrit :

Comments

Only list boxes that have the LBS_HASSTRINGS style can receive this message.

Par conséquent, si tu reçois ces messages, c'est louche... Mais il n'est pas dit non plus que l'on doit obligatoirement répondre à tous les messages que l'on se prend dans la g...

Par contre, pour le message WM_CHARTOITEM, il est bien spécifié :

Comments

Only owner-drawn list boxes that do not have the LBS_HASSTRINGS style can receive this message.

Donc, c'est uniquement aux messages WM_CHARTOITEM que tu dois répondre.

Mais un autre problème se pose : WM_CHARTOITEM répond à un message WM_CHAR, qui lui-même provient de WM_KEYDOWN et de WM_KEYUP selon l'aide de Win 3.1 (Borland Pascal et Delphi 1).

Mais sur l'aide Win 32, il est clairement spécifié que WM_CHAR ne répond qu'à un message WM_KEYDOWN. Cherchez l'erreur...

Néanmoins, il est bien écrit que :

Because there is not necessarily a one-to-one correspondence between keys pressed and character messages generated, the information in the high-order word of the lKeyData parameter is generally not useful to applications.

Donc, inutile de s'appuyer sur le fameux bit 31, car il ne correspond pas forcément au message WM_CHAR que l'on reçoit.

Comme tu travailles sûrement sous environnement 32 bits, j'ose espérer que l'aide de Windows est juste, et que seul un WM_CHAR est envoyé lors de l'appui sur une touche, et non deux. C'est qui plus est bien plus logique comme ça.

Mais reste la compatibilité. Il faudrait savoir si la touche est appuyée, ou bien relâchée. L'information de lParam est selon les dires de Microsoft non fiable (pourquoi la mettre alors ?). C'est plus que gênant.

Il faudra donc tester ton prog sous environnement 16 bits pour savoir s'il fonctionne réellement.

En tout cas, commence par régler le premier problème : WM_VKEYTOITEM ne t'est pas destiné. Alors laisse-le tranquille

J'ai par contre remarqué un truc intéressant. Tu utilises la fonction SendDlgItemMessage. Pourtant, tu as bien le handle de la boite liste (hListe). Alors pourquoi ne pas te servir directement de SendMessage lors de tes communications avec elle ? C'est ce que fait Borland en tout cas (cf l'unité ODialogs).

De plus, mais là je n'y connais absolument rien, Borland indique dans l'aide ceci :

TListBox objects are not normally used in dialog boxes (TDialog)

Or, il semblerait que ce soit ton cas (me trompais-je ?

). Peut-être tends-tu le baton comme on dit...

Sur ce, @++[/code]

**M.Dlb** · 04/07/2003, 01h22

Pour résumer, ton programme répond à deux messages, alors qu'il ne devrait répondre qu'à un seul... Il faudra donc trier :p
Désolé de ne pas avoir été si efficace qu'HDD34 ( j'ai pas l'aide de delphi 1 !! Mais où va-t-il chercher tous ça, HDD34 ?? )...
a+

**Alcatîz** · 04/07/2003, 16h51

Alors là, je n'en sais rien.

Mais vous êtes 'achement forts, les mecs !

Y a un truc : vous avez certainement réussi à caser plus de 100 heures par journée, pour parvenir à être aussi compétents dans absolument tous les domaines !

On ne le voit pas, mais je suis agenouillé, que dis-je ? prosterné !

Bon, je vais oublier ce fameux bit 31 dont Microsoft n'est pas trop sûr. J'ai essayé de créer une méthode de réponse à wm_CharToItem : négatif ! Ce message n'est pas dispatché.

Mais si le type tListBox n'est pas indiqué dans un dialogue tDialog, je ne suis pas sorti de l'auberge. Bref.

Je vais laisser ce problème en suspens et le contourner à l'aide d'un petit dialogue de recherche : ce sera beaucoup moins pratique, mais il faut que j'avance dans mon soft (déjà 11.400 lignes de code !).

Je ferai comme beaucoup d'éditeurs : je règlerai le problème après la sortie du programme, en vendant très cher un "patch".

Encore merci pour vos réponse éclairées et à bientôt !

**Eric Sigoillot** · 04/07/2003, 22h18

Relève-toi !

100h par jour, je n'y avais pas pensé, mais...

En fait, il suffit d'avoir les bons outils, afin de pouvoir trouver ce qu'on cherche rapidement.
En fait, je n'ai jamais développé une seule application avec BPW. C'est tout dire...

L'essentiel, c'est la doc, pour pouvoir répondre à un éventail assez large de question. De mon côté, j'ai (pour le Pascal) :

Borland Pascal : Dos mode réel et protégé et Windows 3.x
Delphi 1 : Windows 3.x (compatible 95)
Delphi 5 : Windows 9x et suivants

Et ce avec les fichiers d'aide qui vont avec.

Pour le développement Dos, j'ai aussi l'indispensable Ralph Brown Interrupts List, et pour le développement Windows, j'ai ajouté à ma collection les MSDN.

Avec ça, on peut déjà débroussailler pas mal de problèmes. La preuve...

A+

**M.Dlb** · 05/07/2003, 00h21

Question documentation, il y aussi la collection HelpPC 2.10 de David Jurgens, malheureusement plus mis à jour depuis 1991

C'est une mine d'or non seulement pour les instructions assembleur du 286 au 486, mais aussi pour tous les formats de données qu'utilisent les différents BIOS, le DOS, les périphériques...
C'est, avec la "RBIL" ( Ralf Brown's Interrupts List ), mes documentations préférées

J'espère que l'on t'a bien aidé Alcatîz, malgré notre incapacité à résoudre totalement le problème... Peut-être devrais-tu faire un tour sur le forum delphi... ( les développeurs delphi purs sont un peu plus au courant de la programmation avancée sous Windows, en général

)
a+

**Alcatîz** · 05/07/2003, 15h10

Et comment, que vous m'avez bien aidé !
Et comme vous dites, une bonne doc est indispensable.

Quant à l'idée du forum Delphi, pourquoi pas ? Il faudrait que je tombe sur des "programmeurs de la première heure", qui ont également pratiqué une programmation proche de Windows comme BPW.

[BPW]Problème de recherche dans une boîte liste

Turbo Pascal

Discussions similaires

Partager

Partager