|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Comment savoir où se trouve le focus actuel ? |
| Débuté par Ntt68, 19 nov. 2015 13:55 - 7 réponses |
| |
| | | |
|
| |
Membre enregistré
104 messages
Popularité : +1 (1 vote) |
|
Posté le 19 novembre 2015 - 13:55 |
Bonjour,
Quelle est la fonction inverse de SetFocus (DonneFocus) ? J'ai besoin d'une fonction qui donne le focus actuel mais je ne parviens pas à la trouver. La fonction ControlCurrent (ChampEnCours) ne me convient pas car elle est spécifique ax champs de saisie. J'ai besoin de savoir si le focus se trouve sur un bouton ou pas.
Merci d'avance
--
NGUYEN Tan Trung
B. Rekencentra NV |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
104 messages
Popularité : +1 (1 vote) |
|
Posté le 25 novembre 2015 - 08:52 |
Je relance, ! Quelqu'un a-t-il une solution ?
Merci d'avance
--
NGUYEN Tan Trung
B. Rekencentra NV |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
397 messages
Popularité : +13 (13 votes) |
|
Posté le 25 novembre 2015 - 16:16 |
Bonjour,
Par principe un bouton ne peut pas avoir de focus : soit on clique dessus soit on clique pas. Avec un curseur on peut avoir un effet "survol" dessus pour montrer qu'on passe sur un bouton, mais ce n'est pas valable en mobile où le curseur est le doigt, et qu'on ne connait pas ses coordonnées tant qu'il n'a pas cliqué sur l'écran.
Quel est le but final recherché exactement ?
Cordialement, |
| |
| |
| | | |
|
| | |
| |
Posté le 25 novembre 2015 - 19:06 |
Bonjour
en l'occurrence, ce n'est pas vrai du tout...
Avec l'ordre de tabulation, un bouton peut absolument avoir le focus, et
s'il n'y a pas de bouton de type validation dans la fenêtre, c'est ce
bouton qui sera activé par la touche ENTER.
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)
Plus d'information sur http://fabriceharari.com
On 11/25/2015 10:16 AM, Benjamin wrote:
Bonjour,
Par principe un bouton ne peut pas avoir de focus : soit on clique
dessus soit on clique pas. Avec un curseur on peut avoir un effet
"survol" dessus pour montrer qu'on passe sur un bouton, mais ce n'est
pas valable en mobile où le curseur est le doigt, et qu'on ne connait
pas ses coordonnées tant qu'il n'a pas cliqué sur l'écran.
Quel est le but final recherché exactement ?
Cordialement, |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
104 messages
Popularité : +1 (1 vote) |
|
Posté le 26 novembre 2015 - 08:51 |
Voici mon problème: Je veux faire la validation lorsqu'on quitte un champ (perd le focus) et j'ai un bouton qui permet de montrer la liste des codes/valeurs valables.
--> Je veux ignorer la validation si on clique sur le bouton. Le problème c'est que l'événement 'quitter le champ' arrive avant le 'clic' ce qui est normal.
--> Lorsque j'attrape l'événement 'quitter champ', je suis pour le moment incapable de savoir que le focus va se trouver sur le bouton.
--
NGUYEN Tan Trung
B. Rekencentra NV |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
397 messages
Popularité : +13 (13 votes) |
|
Posté le 26 novembre 2015 - 12:44 |
Bonjour,
Fabrice Harari a écrit :
Avec l'ordre de tabulation, un bouton peut absolument avoir le focus, et
s'il n'y a pas de bouton de type validation dans la fenêtre, c'est ce
bouton qui sera activé par la touche ENTER.
Vous avez raison, mais vous conviendrez également que l'ordre de tabulation est de manière générale très peu utilisé en Mobile où la touche TAB n'apparait même pas sur aucun des claviers virtuels des plateformes IOS, Android et Windows Phone. Ainsi je ne considère donc pas le traitement "prise de focus" d'un bouton comme étant une solution fiable sur Windev Mobile. Mes tests montrent que le traitement est tout de même activé lors d'un clic, mais dans ce cas-là, autant mettre le code directement dans le traitement du clic...
@ Ntt68 :
Malheureusement les traitements des champs sont complètement indépendants : le traitement de prise de focus ne s'effectue pas tant que le code "Sortie de champ" du champ de saisie n'a pas fini de s'exécuter. Donc, quand bien même la fonction existerait, il est probable qu'elle retournerait le champ de saisie plutôt que le bouton cliqué.
Une solution "overkill" serait une fonction appelée sur un timer qui ferait les vérifications suivant si un booléen global est à vrai ou faux... Et gérer la valeur de ce booléen dans les traitements des champs (gbVerifier = Vrai en sortie de focus du champ de saisie, et gbVerifier = Faux en prise de focus / clic du bouton par exemple).
Une solution plus "light" serait de limiter la vérification au moment de l'envoi du formulaire, mais cela peut ne pas convenir à votre application.
Cordialement, |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
104 messages
Popularité : +1 (1 vote) |
|
Posté le 26 novembre 2015 - 13:29 |
Merci Benjamin et Fabrice,
Je pense que je vais faire 2 validations:
+ Validation "douce" lors de la sortie du champ: montrer le champ dans une autre couleur lorsque la valeur encodée n'est pas correcte (pas de message d'erreur).
+ Validation "dure" avec message erreur lors de l'envoi du formulaire.
--
NGUYEN Tan Trung
B. Rekencentra NV |
| |
| |
| | | |
|
| | |
| |
Posté le 24 mai 2018 - 10:23 |
Bonjour,
Je viens d'être confronté au même problème (c'est pourquoi je déterre le sujet). Je l'ai résolu en utilisant la fonction ChampSuivant() dans le traitement de sortie de champ pour connaître le bouton qui a déclenché la sortie de champ.
Exemple :
-- DANS Sortie de Champ_1 --
SI ChampSuivant() <> "BTN_1" ALORS
effectuerVerification()
FIN
Cette solution a fonctionné pour moi sur Windev 22. Je ne sais pas si cela est valable pour Webdev et Windev Mobile.
Cordialement |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|