Discussion :

[Pierre Fauconnier]

Salut.

Pour info, Access propose un masque de saisie pour les données de type date. Ce masque de saisie permet de saisir une date aberrante durant la saisie et ne valide qu'après saisie. Autrement dit, l'utilisateur est guidé pour une saisie syntaxique correcte, mais la validité de la saisie n'est vérifiée qu'après coup. Je suppose que les développeurs d'Access ont voulu ainsi éviter l'usine à gaz qui ne manquait pas de se profiler.

Quoi qu'il en soit, il me semble délicat de vérifier la bonne saisie d'une date durant la saisie, puisque l'on va devoir partir du principe que la partie saisie est correcte pour valider la suite, ce qui est un postulat erroné. Ainsi, si on saisit 29/02/, il va falloir partir du principe que la saisie est correcte pour empêcher de saisir une année non bissextile, alors que c'est peut-être le 29 qui est erroné, ou le 02. Il faut donc permettre le retour en arrière sauf à brider l'utilisateur et à lui interdire, par exemple, le retour en arrière (manipulation intuitive et attendue par l'utilisateur). C'est pourquoi, outre le sport que cela peut représenter, il me paraît inutile, et probablement impossible sans usine à gaz, de tenter de réaliser cela. Il me semble plus raisonnable de se contenter de valider ou d'invalider la saisie après coup, éventuellement en contrôlant la saisie selon un masque de saisie (syntaxe) mais sans valider au fur et à mesure... Et n'a pas encore été envisagé ici le copier/coller d'une donnée.

C'était mon grain de sel, nonobstant qu'il peut être très amusant et sportif d'essayer quand même (en dehors d'un objectif de rentabilité et d'utilisation professionnelle de ce qui sera produit)

[pijaku]

Bonjour Pierre,

Selon moi un contrôle en cours de saisie n'est là que pour vérifier que l'utilisateur ne saisit pas :
- de jours inférieurs à 01 et superieurs à 31,
- de mois non compris entre 01 et 12,
- d'années non prises en compte par l'application.
Le reste, (les 31 et autres 29/02) sont des exceptions (8 dates par an!).
Ils peuvent être traités:
- pour les 31 (ex : 31/04) dès la saisie du mois et ou du jour selon le format de date (donc pour le format aaaa/mm/jj en fin de saisie),
- pour les 29/02 en fin de saisie.
Toujours selon moi, il ne faut pas bloquer l'utilisateur et le laisser, à tout instant, naviguer dans son TextBox. Le seul blocage à lui opposer est la sortie si saisie invalide.

Le développeur doit également penser à:
- la saisie d'une valeur par le code,
- le copié collé,
- la sortie par la souris.
Pour ces 3 cas, il existe, pour le contrôle TextBox, un événement adéquat.

A partir de cette base, je ne vois pas pourquoi ce principe ne saurait être appliqué à une appli pro...

Ma question existentielle sur ce sujet est la suivante :
Comment doit réagir le code en cas de mauvaise saisie?
Doit-on :
- supprimer la dernière saisie qui a engendré l'erreur?
- afficher un MsgBox?
- sélectionner la saisie en erreur?
- effacer tout?
- autre solution?
Le progiciel dont je parlais plus haut supprime le dernier "segment" de date saisit. Si le mois engendre une erreur (ex 31/04) il le supprime (résultat: 31/__/____). Si c'est le jour (ex 33/__/____) il le supprime (résultat : __/__/____).
Vos avis éclairés à cette question m'aiderait beaucoup.
Mais je crois bien qu'il n'y a pas de solution universelle qui plaira à tous...
A++
Franck

[patricktoulon]

Bonjour a tous
@pierre

oui pour une saisie incomplete a verifier on utilise une date complete théorique c'est le principe que l'on utilise pijaku et moi
a savoir par exemple
quand on tape 29/02 on teste 29/02/2000 le "2000" et théhorique tant que les 4 chiffre de l'année ne sont pas tapés
quand on tape 31/__/____ on teste 31/01/2000
quand on tape 31/2_/____ on teste 31/02/2000 pour pijaku tandis moi je stope car théoriquement on depasse les 12 c'est sur ce point que nous divergeons pijaku et moi


de cette maniere on a pas de plantage surtout pour le mois de fevrier quand on a pas finie d'entrer la date

pour l'ergonomie effectivement cela peut varier d'un utilisateur a l'autre perso j'ai préféré travailler en segment pour la navigation intuitive et mid(segment,1,1) et val(segment) pour la saisie

pour le reste tout a fait d'accords c'est du sport ( du fun)

reste que le model le plus simple et fonctionel sans fioriture (couleur ,etc....)et bien pratique pour moi par exemple avec mes gros doigts surtout que le code ne fait pas plus d'une 30 aine de lignes

pijaku hier j'ai testé j'ai adapté ma methode a ton userform et ca match , moins de 100 lignes pour tout les format tel,secu,iban,date,heure,etc....)
la gestion de couleur un peu differente le green ne m'interesse pas je remet la couleur initiale et toujours sans variables static ou globale

me reste a créer une fonction similaire a ta fonction ispecialday qui est interessante

@pijaku

Le développeur doit également penser à:
- la saisie d'une valeur par le code,
- le copié collé,
- la sortie par la souris.
Pour ces 3 cas, il existe, pour le contrôle TextBox, un événement adéquat.

j'ai pas regardé comment tu a fait mais avec ma methode le ctrl+C est impossible vue que le selectcase keycode ne le laissera pas passer
pour la saisie on l'a vu le before update avec le test activecontrol
pour l'exit avec la souris pas testé

[RyuAutodidacte]

Re Franck,

- de jours inférieurs à 01 et superieurs à 31,
- de mois non compris entre 01 et 12,
- d'années non prises en compte par l'application.

Je suis tout à fait d'accord avec cela, c'est sur ce principe que je suis parti

Le reste, (les 31 et autres 29/02) sont des exceptions (8 dates par an!).
Ils peuvent être traités:
- pour les 31 (ex : 31/04) dès la saisie du mois et ou du jour selon le format de date (donc pour le format aaaa/mm/jj en fin de saisie),
- pour les 29/02 en fin de saisie.

Même réflexion, mais doit t-on proposer plusieurs format de saisi.
En y réfléchissant je me dis que le mieux est de proposer seulement le format le plus logique pour la vérification (aaaa/mm/jj => donc vérification en cours et en fin de saisie pour validation), sachant que l'on pourra en sortie donner le format souhaité (jj/mm/aaaa ou aaaa/mm/jj , etc…)
Du coup on simplifie et en quelque sorte on éduque les utilisateurs à des mécanismes imposés permettant au final plus de sérénité …
Quelque soit les logiciels (plus ou moins bien faits) les utilisateurs se conforment au fonctionnement du/des logiciels qu'ils utilisent tel qu'ils ont été fait

Ma question existentielle sur ce sujet est la suivante :
Comment doit réagir le code en cas de mauvaise saisie?

Je pense que au-delà du mécanisme que l'on veut créer pour l'utilisateur, il est peut être important de se poser la question quel sera la réaction de l'Utilisateur (général à tout utilisateur globalement) face à une situation donnée :

Exemple tout bête :
"- effacer tout?" (pas forcément le moyen le plus pratique mais …) => que fera l'utilisateur => tient tout s'est effacer, j'ai du faire une erreur, je vais faire plus attention en entrant ma saisie => on le responsabilise à ce qu'il fait

Pour :
"- sélectionner la saisie en erreur?" => se fera seulement au moment de la vérification selon le format de date
je dirais plutôt "effacer et sélectionner la partie du masque à corriger (Est ce une bonne solution ??)

"- afficher un MsgBox?" => bcp plus clair car donnera des précisions (assistanat) et obligera à plus de manipulations

Je reste pour l'instant sur le format à saisir aaaa/mm/jj et d'avoir en sortie le format souhaité
comme l'a dit @Menhir et d'autres dont moi, il est important de responsabilisé les utilisateurs (bien sur il faut aussi leur simplifier les mécanismes et de façon intuitif), mais :

Mais je crois bien qu'il n'y a pas de solution universelle qui plaira à tous...

et je suis entièrement d'accord avec toi

Edit : j'ai mis un peu de temps à écrire mon message, du coup je t'ai croisé Patrick