Je trouve pratique que la touche d'=E9chappement permette de s=E9lectionn=
er=20
le bouton qui ferme le sous-formulaire, et laisse ensuite =E0=20
l'utilisateur le temps de changer d'avis.
La propri=E9t=E9 Cancel du bouton a le m=E9rite de la simplicit=E9, mais =
elle=20
d=E9clenche directement l'action OnClick du bouton d=E8s qu'on a press=E9=
=20
Echappement, y compris pour annuler une saisie. Il arrive donc que ce=20
soit un peu trop radical et prenne l'utilisateur par surprise.
J'ai donc pr=E9f=E9r=E9 g=E9rer Form_KeyPress, plus souple mais, forc=E9m=
ent, plus=20
astreignante.
Bien entendu, il faut mettre l'aper=E7u des touches du formulaire =E0 Vra=
i.
Ensuite, ce n'est pas fini.
Depuis le formulaire principal, =E7a se passe bien.
J'ignore si j'ai loup=E9 une propri=E9t=E9 qui m'aurait fait gagner du te=
mps,=20
mais lorsqu'un sous-formulaire est s=E9lectionn=E9, c'est la proc=E9dure =
Form_KeyPress du sous-formulaire qui est utilis=E9e, sous r=E9serve que=20
l'aper=E7u des touches du sous-formulaire soit activ=E9, sinon c'est g=E9=
r=E9 au=20
niveau du contr=F4le.
=E7a se pr=E9sente donc comme =E7a :
- le Form_KeyPress du formulaire principal est Public
- dans le sous-formulaire :
Public Sub Form_KeyPress(KeyAscii As Integer)
If KeyAscii =3D 27 Then Parent.Form_KeyPress 27
End Sub
Et, bien entendu, la m=EAme chose =E0 chaque niveau de sous-formulaire, l=
e=20
dernier niveau pouvant sans probl=E8me avoir une Form_KeyPress en Private=
=20
(tant qu'il reste en dernier niveau).
Et, de fait, lorsque j'appuie sur Echappement, le bouton de fermeture=20
est s=E9lectionn=E9.
L=E0 o=F9 je commence =E0 devenir pinailleur, c'est que lorsqu'on a comme=
nc=E9=20
une saisie, on l'annule avec Echappement, et dans ce cas, je trouve=20
qu'on pourrait s'en tenir l=E0. Eventuellement, une deuxi=E8me pression s=
ur=20
Echappement pourrait faire s=E9lectionner le bouton.
Or, la propri=E9t=E9 Dirty, active pendant qu'on modifie des donn=E9es,=20
s'annule d=E8s qu'on presse sur Echappement, avant que KeyPress soit=20
ex=E9cut=E9e, donc on ne peut pas compter dessus pour diff=E9rencier le=20
traitement.
Comme en plus les proc=E9dures de traitement des touches sont ex=E9cut=E9=
es=20
avant celles de traitement des donn=E9es, du moins celles sur lesquelles =
j'ai eu l'id=E9e de mettre des pauses ...
Ou alors activer un bool=E9en lorsqu'on traite une touche de caract=E8re =
?
Peut-=EAtre y a-t-il une solution plus =E9l=E9gante ?
Pour le moment je travaille sous Access 2003 SP2, Windows XP Pro 2002=20
SP2, sur une base au format Access 2000.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
"Gloops" Je trouve pratique que la touche d'échappement permette de sélectionner le bouton qui ferme le sous-formulaire, et laisse ensuite à l'utilisateur le temps de changer d'avis.
La propriété Cancel du bouton a le mérite de la simplicité, mais elle déclenche directement l'action OnClick du bouton dès qu'on a pressé Echappement, y compris pour annuler une saisie. Il arrive donc que ce soit un peu trop radical et prenne l'utilisateur par surprise.
J'ai donc préféré gérer Form_KeyPress, plus souple mais, forcément, plus astreignante. <snip>
Je m'arrête là ;-)
Plus souple - plus astreignant...
Il a souvent été question de la touche Escape ici, mais il faut reconnaître que, sauf cas très particulier - et dans ce cas on a de bonnes raisons - cette touche ne devrait pas être détournée.
Si l'on a pas ces bonnes raisons, il suffit d'éduquer/former l'utilisateur ;-)
Ceci dit, on peut se limiter à regarder si on est en mode édition au niveau du formulaire (dirty) et si non annuler le cancel par un keycode=0
"Gloops"
Je trouve pratique que la touche d'échappement permette de sélectionner
le bouton qui ferme le sous-formulaire, et laisse ensuite à
l'utilisateur le temps de changer d'avis.
La propriété Cancel du bouton a le mérite de la simplicité, mais elle
déclenche directement l'action OnClick du bouton dès qu'on a pressé
Echappement, y compris pour annuler une saisie. Il arrive donc que ce
soit un peu trop radical et prenne l'utilisateur par surprise.
J'ai donc préféré gérer Form_KeyPress, plus souple mais, forcément, plus
astreignante.
<snip>
Je m'arrête là ;-)
Plus souple - plus astreignant...
Il a souvent été question de la touche Escape ici, mais il faut reconnaître
que, sauf cas très particulier - et dans ce cas on a de bonnes raisons -
cette touche ne devrait pas être détournée.
Si l'on a pas ces bonnes raisons, il suffit d'éduquer/former l'utilisateur ;-)
Ceci dit, on peut se limiter à regarder si on est en mode édition au niveau
du formulaire (dirty) et si non annuler le cancel par un keycode=0
"Gloops" Je trouve pratique que la touche d'échappement permette de sélectionner le bouton qui ferme le sous-formulaire, et laisse ensuite à l'utilisateur le temps de changer d'avis.
La propriété Cancel du bouton a le mérite de la simplicité, mais elle déclenche directement l'action OnClick du bouton dès qu'on a pressé Echappement, y compris pour annuler une saisie. Il arrive donc que ce soit un peu trop radical et prenne l'utilisateur par surprise.
J'ai donc préféré gérer Form_KeyPress, plus souple mais, forcément, plus astreignante. <snip>
Je m'arrête là ;-)
Plus souple - plus astreignant...
Il a souvent été question de la touche Escape ici, mais il faut reconnaître que, sauf cas très particulier - et dans ce cas on a de bonnes raisons - cette touche ne devrait pas être détournée.
Si l'on a pas ces bonnes raisons, il suffit d'éduquer/former l'utilisateur ;-)
Ceci dit, on peut se limiter à regarder si on est en mode édition au niveau du formulaire (dirty) et si non annuler le cancel par un keycode=0
Ceci dit, on peut se limiter à regarder si on est en mode édition a u niveau du formulaire (dirty) et si non annuler le cancel par un keycode=0
Oui, c'est bien l'idée que j'ai eue, mais comme je disais le Dirty est "nettoyé" avant l'exécution des procédures de touches notamment Key Press. Et si je ne m'abuse les procédures de traitement de données arrivent après, donc on ne peut pas le mémoriser à partir de là.
C'est vrai qu'on pourrait préférer une autre touche pour la sortie, b on, à défaut d'autre chose, c'est peut-être comme ça que ça va fini r.
Merci.
3stone a écrit, le 21/11/2007 23:01 :
Ceci dit, on peut se limiter à regarder si on est en mode édition a u niveau
du formulaire (dirty) et si non annuler le cancel par un keycode=0
Oui, c'est bien l'idée que j'ai eue, mais comme je disais le Dirty est
"nettoyé" avant l'exécution des procédures de touches notamment Key Press.
Et si je ne m'abuse les procédures de traitement de données arrivent
après, donc on ne peut pas le mémoriser à partir de là.
C'est vrai qu'on pourrait préférer une autre touche pour la sortie, b on,
à défaut d'autre chose, c'est peut-être comme ça que ça va fini r.
Ceci dit, on peut se limiter à regarder si on est en mode édition a u niveau du formulaire (dirty) et si non annuler le cancel par un keycode=0
Oui, c'est bien l'idée que j'ai eue, mais comme je disais le Dirty est "nettoyé" avant l'exécution des procédures de touches notamment Key Press. Et si je ne m'abuse les procédures de traitement de données arrivent après, donc on ne peut pas le mémoriser à partir de là.
C'est vrai qu'on pourrait préférer une autre touche pour la sortie, b on, à défaut d'autre chose, c'est peut-être comme ça que ça va fini r.
