Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Est-ce que quelqu'un connaît un moyen de faire croire au système que la touche ctrl est enfoncée alors qu'elle ne l'est pas réellement ?
Merci
Hors ligne
Hors ligne
pick ouic a écrit:
salut,
pourquoi ?
Parce que j'ai plusieurs événements de plusieurs objets qui s'enchaînent suite au keyenter! Et que au milieu du deuxième événement, keydown(keyenter!) me retourne false ... (alors qu'au début de ce deuxième événement, il me retourne true)
Hors ligne
méfie toi de ce que tu vois en débug, si tu débugge et que ton doigt n'est plus sur la touche ...
Hors ligne
Je l'ai testé autant en debug qu'en utilisant un MessageBox ou en modifiant dynamiquement le titre de la fenêtre ...
Je sais, ce n'est pas possible ... Keydown(keyenter!) devrait retourner true uniquement pour le premier événement et false pour les suivants ...
Je ne sais pas si c'est du aux caractéristiques du processeur de mon poste de travail ou aux caractéristiques du clavier que j'utilise ... En tous cas, c'est bancale !
Je reformule ma question : comment faire savoir au deuxième objet que le déclenchement de ses événements provient du déclenchement d'un événement (keypressed = keyenter!) du premier (et ceci sans passer par une variable d'instance ni par une variable globale) ?
Hors ligne
BRWA a écrit:
Je l'ai testé autant en debug qu'en utilisant un MessageBox
mauvaise méthode aussi, imagine que tu débugge l'event activate d'une fenêtre avec un messagebox... => infinite loop
10 rentre dans event activate
20 messagebox
30 click ok/cancel messagebox => rends le focus à la fenêtre
40 goto 10
BRWA a écrit:
ou en modifiant dynamiquement le titre de la fenêtre
bonne solution ;-)
sinon à mon avis t'as plus un problème de design au niveau de ton appli qu'un problème technique (oui je sais ça t'aide pas...)
Hors ligne
Je l'ai testé sur un autre pc (autres données techniques et autre clavier), et ça me donne un résultat différent : le keydown(keyenter!) me retourne false au début du second event.
Je ne vois comme conclusion que le fait que celà soit dû au temps de réponse du clavier ...
Quoi qu'il en soit, je me suis débrouillé autrement en contrôlant les événement pbm_lbuttonup et pbm_lbuttondown ...
rincevent a écrit:
BRWA a écrit:
Je l'ai testé autant en debug qu'en utilisant un MessageBox
mauvaise méthode aussi, imagine que tu débugge l'event activate d'une fenêtre avec un messagebox... => infinite loop
10 rentre dans event activate
20 messagebox
30 click ok/cancel messagebox => rends le focus à la fenêtre
40 goto 10
Je fais attention à ce genre de désagrément . De plus, je ne code pour ainsi dire jamais l'événement activate ... (en fait, je n'ai pas encore rencontré un cas de figure pour lequel j'en avais besoin)
Dernière modification par BRWA (29-06-2009 08:50:13)
Hors ligne
BRWA a écrit:
Quoi qu'il en soit, je me suis débrouillé autrement en contrôlant les événement pbm_lbuttonup et pbm_lbuttondown ...
sont plus à un bidouillage près chez PMIGest de toutes façon si ?
bon courage et bonne chance à toi
Hors ligne
rincevent a écrit:
sont plus à un bidouillage près chez PMIGest de toutes façon si ?
Non, leur logiciel est clair et tend à l'être de plus en plus ! K.I.S.S. !
Hors ligne
BRWA a écrit:
rincevent a écrit:
sont plus à un bidouillage près chez PMIGest de toutes façon si ?
Non, leur logiciel est clair et tend à l'être de plus en plus ! K.I.S.S. !
Ha ha haaaa... Keep It Simple and Stupid... Je revois encore Mr Verstichel me le dire tiens...
Maintenant, si tu me dis que pmiX est devenu clair, alors là... je suis estomaqué, comme on dit chez moi...
;)
Maintenant, pour revenir sur ton problème, pourrais-tu nous expliquer où exactement tu fais ton keydown(), quel évènement initie ton processus, pourquoi tu as besoin de faire 2 'keydown',... ?
Hors ligne
Je n'ai plus besoin de faire deux keydown, je me suis débrouillé autrement ...
Mais j'ai remarqué que lorsque je suis en focus d'un singleline edit dont le keypressed est codé pour initier un changement sur une dw après un keyenter (recherche de ligne dont la première colonne ressemble au texte dans le sle), et que dans le keyenter on a dw.TriggerEvent (Clicked!), ... et bien quand je teste keydown(keyenter!) dans ce clicked, j'ai true jusqu'à la ligne 15 ... (et donc false à partir de la ligne 16)
Dernière modification par BRWA (01-07-2009 05:55:29)
Hors ligne
BRWA a écrit:
Mais j'ai remarqué que lorsque je suis en focus d'un singleline edit dont le keypressed est codé pour initier un changement sur une dw après un keyenter (recherche de ligne dont la première colonne ressemble au texte dans le sle), et que dans le keyenter on a dw.TriggerEvent (Clicked!), ... et bien quand je teste keydown(keyenter!) dans ce clicked, j'ai true jusqu'à la ligne 15 ... (et donc false à partir de la ligne 16)
Oui, mais d'après moi, c'est tout à fait correct... On parle bien de la fonction 'keydown()' qui renvoie un boolean? Si oui, c'est normal! En principe, tu n'est censé l'appeller qu'une seule fois et puis basta...
Imagine ce que fait cette fonction: à un moment t, elle vérifie si la touche spécifiée a été pressée. Mais il faut bien qu'un jour ou l'autre la fonction te renvoie false, d'autres touches étant pressées par après... Donc tu ne dois tester la dernière frappe qu'une seule fois, puisque pendant que ton script est exécuté par PB la situation va fatalement évoluer, et ce de manière différente d'une machine à l'autre (mode d'implémentation du buffer IO du keyboard) et d'un RUN à l'autre (occupation CPU à ce moment...)
Le mieux dans ce cas est de travailler sur l'argument key de l'event keydown, keypressed, keyup ou je ne sais plus quoi...
Hors ligne