Discussion :

[Gluups]

Bonjour tout le monde,

J'ai l'impression que j'ai dû oublier un truc que j'ai su ...

J'ai écrit un éditeur de texte, qui dans l'ensemble fonctionne plutôt pas mal, sauf que l'utilisatrice a une fâcheuse tendance à donner de la souris où il ne faut pas, ce qui fait que l'application perd le focus.

Je pourrais mettre le formulaire en modal, mais ça me paraît un peu catégorique, des fois qu'il y ait vraiment quelque chose à aller voir dans les autres applications.

Alors ... Je me suis fait un nœud au cerveau, et j'ai écrit un timer pour vérifier si le verrouillage des majuscules a changé.

Si c'est le cas, en plus de changer la couleur de fond et émettre un bip, j'exécute ça :

Code :

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

1
2
3
                            this.Activate();
                            this.BringToFront();
                            this.Focus();

Tant que c'est exécuté en débogage depuis Visual Studio, ça fonctionne impec.

Mais dès que l'application est lancée indépendamment, le changement de couleur de fond se fait mais l'application ne reprend pas le focus. Pas mieux avec SetForegroundWindow et SetActiveWindow.

Alors j'ai un peu triché :

Code :

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

1
2
3
4
5
6
    IntPtr hWnd = GetForegroundWindow();
 
    if (hWnd != this.Handle)
    {
          SendKeys.SendWait("%{esc}");
    }

Ça marche, mais je suppose qu'on doit pouvoir faire ça proprement ?

[popo]

C'est bizarre comme concept :
Quel est le rapport entre une perte de focus et le verrouillage majuscule ?

Et en règle générale, lorsqu'un utilisateur clique sur un autre fenêtre fenêtre, c'est volontaire.
Imagine que tu dois répondre à un mail et qu'une autre application reprenne systématiquement le focus.
Je ne sais pas pour toi, mais moi, ça va vite me gaver.

[Gluups]

Tu as mal suivi : la mise en majuscules n'est pas en rapport avec la perte de focus, mais avec la reprise. Il fallait quelque chose de simple à disposition sur le claver.
Aucun clic à l'extérieur n'était volontaire.
La messagerie est fermée.

[popo]

Tu as mal suivi : la mise en majuscules n'est pas en rapport avec la perte de focus, mais avec la reprise. Il fallait quelque chose de simple à disposition sur le claver.

Nulle part dans ta demande, tu ne précises que le timer et le changement de couleur sont effectués à la reprise de focus, tu ne parle que de perte de focus.

En plus le code montré fait un SetFocus qui n'a aucune raison d'être effectué si l'application possède déjà le focus.
Avec ces seules informations, il est compliqué de "deviner" qu'il est question de reprise de focus.
Nous ne sommes pas dans ta tête, il faut dire les choses clairement.
Mais passons...

Mais du coup, tu ne précise toujours pas clairement quel impact a le verrouillage majuscule lors de la reprise de focus (pour moi, il ne devrait pas en avoir).
Si ton changement de couleur est déclenché par un Timer, il est, par nature, indépendant de la reprise de focus.

Aucun clic à l'extérieur n'était volontaire.

Si tu développes une application prévue spécifiquement pour être accessible à des personnes ayant un handicap quelconque jouant sur la motricité des membres supérieurs, alors il faut adapter l'application par d'autre moyens (fenêtre modale avec un bouton spécifique lorsqu'on veut volontairement changer de fenêtre, ne pas utiliser la souris, etc.). Sur le net tu trouveras des sites qui proposent pas ma de solutions pour l'accessibilité.

Mais si c'est pour une personne lambda, il faut la former à l'utilisation d'un ordinateur avant de lui confier un logiciel.
Perdre le focus en cliquant sur une deuxième application est un comportement normal et attendu.
Il n'est jamais bon d'imposer un comportement qui n'est pas naturel à tous les utilisateur uniquement parce que l'un d'eux est un cliqueur compulsif.

La messagerie est fermée.

Ce n'était qu'un exemple pour démontrer que forcer la reprise de focus est une mauvaise idée.
Par ailleurs, à moins d'avoir du code spécifique empêchant l'ouverture de la messagerie, tu ne peux affirmer que ce sera toujours le cas.

[Gluups]

Bon, il faut que je représente tout ça ...

L'application sert à communiquer, de façon simplifiée, alors que l'utilisation du téléphone pose différents problèmes : on tape chacun à son tour, dans deux champs de saisie. Une personne directement sur le clavier de la machine, dans le premier champ de saisie, l'autre par prise de contrôle à distance, dans le deuxième champ de saisie.

Les machines ne sont a priori pas utilisées pour autre chose pendant la session, sauf pour répondre à une question qui se pose pendant la conversation.

La première personne a du mal avec le clavier et avec la souris, et sa frappe est fréquemment interrompue par la perte de focus, il semble qu'un clic intempestif se produise, qui place le focus sur un des raccourcis du bureau. Alors on sélectionne à nouveau l'application de communication, en cliquant dessus, ça fait perdre du temps.

J'ai développé la première version en un quart d'heure, c'est ensuite que s'est présenté le problème de clic malencontreux.

[AJOUT]
L'application a déjà servi plusieurs fois, la question ne s'est pas posée d'interrompre la session de communication pour effectuer une saisie ailleurs, par exemple d'un mail.
Dans ce cas, il est possible de tester l'état du formulaire : tant qu'il est réduit en icône, le rétablissement de focus restera sage comme une image. Ce qui évite le problème, tout en restant, certes, un moyen de se raccrocher aux branches. Mais la branche a l'air costaud.
[/AJOUT]

Alors je vais effectivement faire quelque chose d'assez inhabituel : entamer une formation à l'utilisation du clavier à quelques centaines de kilomètres de distance. Ne serait-ce que pour moins risquer de confondre verrouillage majuscules et tabulation, qui certes sont très proches sur le clavier, mais en plaçant sa main selon les standards dactylographiques, ça doit pouvoir s'éviter.

L'application peut aussi être un point de départ pour réfléchir à d'autres applications avec diverses difficultés d'utilisation de l'interface, dues notamment à des difficultés cognitives.

Pour le moment, à la lumière de quelques essais, j'ai obtenu ce que je voulais : lorsqu'un clic malencontreux a mis le focus ailleurs que sur l'application alors qu'on voulait y rester, deux pressions sur la touche de verrouillage majuscules corrigent le tir en "moins de deux".

L'application ne respecte certes pas les standards habituels. Entrer du texte à deux personnes en partageant dans le temps la même entrée standard, c'est un peu de l'improvisation. Ça m'a évité de déclarer des canaux de communication à distance : ça pour que ça tienne dans le quart d'heure de développement, il faut l'avoir déjà fait. Je me demandais toutefois si le recours à la simulation de touches pouvait être évité, pour éviter sa grande dépendance au contexte.

Le fait que le résultat obtenu soit différent pour le programme obtenu au final, en le lançant avec un raccourci, ou pendant le débogage sous Visual Studio, me rappelle vaguement quelque chose, je crois que la question a été abordée un jour, mais ... je ne me rappelle pas vraiment ce qui a été dit.

[popo]

Je suis d'accord avec toi sur le fait d'éviter d'avoir recours à la capture de touches.
Suivant la sensibilité du clavier, la configuration de la répétition de touches dans les paramètre de Windows et la personne en face, il est très facile de se retrouver avec de faux positifs.

Je suggère un écran maximisé et StayOnTop.
De cette manière, la fenêtre prend tout l'écran et cela réduit fortement les chances de cliquer sur une autre application par inadvertance.
Et, si on veux vraiment aller sur une autre application, on réduit la fenêtre.

[Gluups]

Hum, la simulation de touche qui active la répétition, pas encore vu ...
En revanche ça m'est arrivé, alors qu'une touche avait du mal à se relâcher à cause d'une étiquette posée à côté pas suffisamment soigneusement, de devoir écrire une application pour la simuler, là plus de problème. Et la touche s'est mise à fonctionner correctement depuis, bon ça c'est une autre question.

Effectivement, en affichant l'application en plein écran, les clics intempestifs seraient internes à l'application, ça limite les dégâts, ou alors après il reste la barre des tâches, mais ce n'est pas le plus fréquent.

Apparemment, j'ai dû inventer ces souvenirs d'une discussion sur les différences de réaction d'une application selon comment elle est lancée.

Merci pour les conseils.