Hihi hi !Un avis personnel partagé et partageable alorsEnvoyé par ouskel'n'or
Mais comme tu dis, ce n'est qu'un avis personnel... que je partage bien volontier
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Hihi hi !Un avis personnel partagé et partageable alorsMais comme tu dis, ce n'est qu'un avis personnel... que je partage bien volontier
Désolé de ne pas avoir le même avis que vous, messieurs...
Le fait est que j'ai fait "reprendre", après analyse et réflexions partagées en commission ad hoc, des quantités d'applications qui ne contrôlaient qu'in fine.
Pour convaincre, les choses ont été simples : avis majoritaire des utilisateurs finaux (les clients, donc) et non des développeurs (les vendeurs, donc) ....
Et il y a une règle : c'est le client qui est le roi... et... le juge final
Lorsque l'incohérence est décelable, elle doit être dénoncée immédiatement et pas (comme on le voit justement bien trop souvent, en effet, sur certains sites), une fois que tout est saisi !!!
Il existe bien évidemment des cas où la chose n'est pas toujours possible, mais ils sont assez rares...
Fort bien !
Nous serons donc plusieurs à avoir des avis partagésmais différents.
Comme quoi, le client doit être roi.
A ceci près que, dans mes écrits, j'indiquais que c'était suite à des DEMANDES des clients, et que je n'ai donc pas eu à les CONVAINCRE comme indiqué ci-dessus
Ceci donnera, qui plus est, aussi bien à petibonhom qu'à tout lecteur l'opportunité de se faire sa propre opinion, tout en la partageant avec l'un de nous trois
J'ajoute simplement qu'après s'être trompé trois fois et avoir été renvoyé au champ qui va bien, l'utilisateur fait attention à ce qu'il saisit, ce qui n'est pas un mal.
Mais ce encore qu'un avis personnel qui ne demande qu'à être partagé... Donc tant pis s'il ne l'est pas
Euh...
Bonjour Ousk,
Tu as quand même remarqué que VB (VBA également) a quant à lui mis le maximum en oeuvre pour te traiter plus gentillement, non ?
Il ne parvient pas toujours à appeler ton attention sur tout, mais il me semble qu'il s'efforce de le faire, chaque fois que possible, avant même ta compilation... et ne te dis pas ... "voilà, c'est bien fait pour toi... t'auras qu'à faire attention la prochaine fois... et ça te fera du bien ...", lui
Mauvais exemple pour accréditer ta thèse, bien au contraire, j'irai jusqu'à dire que c'est un contre-exemple
- Mais il communique, lui ! Il ne m'efface pas ma saisie sans rien dire, comme le fait le code indiqué ci-dessus.
- Et puis, il m'aide à la saisie aussi... Si on doit faire le parallèle, tant qu'à faire, autant proposer un genre de calculatrice pour faire de la saisie numérique dans un contrôle texte, comme cela, plus d'erreur possible, comme la liste de complétion.
- Et puis, il ne fait la remarque sur l'erreur QUE lorsque l'on change de ligne, donc lorsque je suis sensé l'avoir terminée, en fait... lorsque je la quitte, pas à chaque fois qu'on la change d'un caractère
- Et, même lorsqu'on compile, il ne me montre pas les fuites mémoires, ni les erreur d'exécution dûes à sa permissivité, erreur que je ne verrai que bien plus tard encore, lors de l'exécution, et pas pendant que je suis en train de faire ma saisie...
Communiquer ?
Ben (si c'est là vraiment indispensable pour une chose aussi évidente) : il suffit de remplacer le beep par un msgbox (bien que je sois persuadé de ce que celà empoissonnerait plutôt l'existence de l'utilisateur).
Bon... je vais malgré tout retenir cette idée de "communication utile" tout en préservant les nerfs de l'utilisateur érourdi ou à gros doigts (comme moi). Mes applications comporteront donc un onglet de menu laissant à l'utilisateur le choix entre revevoir ou non un msgbox (à cliquer) juste pour lui dire "ce que vous avez frappé là - la dernière touche utilisée - ne peut faire partie d'un nombre et a donc été annulé... recommencez en faisant attention à vos touches de clavier, s'il vous plait) !
Si c'est le seul aspect retenu, je t'invite à faire un évènement sur sortie, pour n'avoir le message qu'une seule fois, alors
Mais il y avait bien d'autres éléments dans ton contre exempleCelui-ci étant le moindre...
Secrétaire eu téléphone et ... au clavier...
- "oui, Monsieur Durand, j'ai pris note des spécications de votre produit. C'est déjà enregistré. Quel est son prix ?"
- "il coûte 25 131 euro et 31 cents, Mademoiselle"
- "zut alors... j'ai mal frappé et c'est refusé par ma machine ! pardonnez-moi ! Vous aviez dit combien, déjà ?"
- "25 131 euro et 31 cents, Mademoiselle"
- et "m**de alors ... encore trompée.... pourquoi diable cette purée de machine a-telle laissé passer un é accent aigü là où il fallait un chiffre ? ... Excusez-moi, hein ... vous aviez dit combien, déjà ?"
Je pense sérieusement qu'il manque ici l'avis d'un tiers...
J'ai eu à développer une appli dans laquelle l'utilisateur avait 128 champs à renseigner. La plupart étaient une simple sélection dans des listes. Des dates, des noms, des horaires, des codes, etc...
Par contre, j'avais à vérifier que les 128 champs étaient bien et correctement renseignées.
Après avoir testé la vérification des données en cours de saisie, j'ai vite compris que mon appli allait dépasser les 10000 lignes. Or, en testant les erreurs possibles (oublis ou erreurs de saisie) lors de la validation de la page, j'ai pu limiter mon code à un cinquantaine de lignes, messages compris.
Donc, mon avis : Il est plus facile de vérifier 50 lignes de code bien rangé dans un coin que 10000 lignes éparpillées dans une appli.
C'est mon avis et je ne le partage qu'avec ceux qui veulent bien le partager
Bonsoir, histoire d'en remettre une couche
Ouais...
J'ose à peine parler, dans ce cas, de ce que m'efforce de faire dans les cas de saisies dépendantes les unes des autres , genre :
saisie obligatoire
saisie à sauter si
saisie obligatoire si
etc... etc...
Suffit de faire une application d'état-cil pour comprendre de quoi il retourne....
Le confort de l'utilisateur est extrêmement important.
Une secrétaire comme cela ne le reste pas longtemps !
Bref, deuxième contre-exemple...
- Ne sait pas taper au clavier (faute lourde pour une secrétaire)
- Ne sait pas qu'elle doit demander une trace écrite en provenance de la société émettrice, car sinon, le devis n'a aucune valeur -puisqu'il n'y en a pas eu (deuxième faute lourde)
- Incompétente au niveau technologies, puisque ne sait ni se servir d'un fax, ni des emails, ni des courriers, et fait tout par téléphone (cf pt n°2)
Mis, à force de chercher des exemples, tu en trouveras peut-être un qui comblera toutes les exigences énumérées plus haut !
Avec on Exit, c'est parfaitement réalisable...
Tout est facile... tout ... et pas seulement avec Excel...
On met de telles choses en oeuvre, toutefois, alors même qu'il suffirait que l'utilisateur :
- saisisse les champs obligatoires
- ne saisisse pas les champs à ignorer
- détermine quel champ est à ignorer ou à saisi en fonctions des saisies précédentes...
On lui facilite la tâche au fur et à mesure, de façon conditionnelle, n'est-ce pas ?
On ne vérifie pas ce qu'il a fait lorsqu'il a fini de saisir ... (ce qu'on pourrait faire) ...
Voilà l'esprit. Et Je suis heureux de ce que certains logiciels permettent de programmer ainsi (et facilitent ce développement) et non à la, hussarde ...
Et avec ce qui convient : on n'attend pas le exit d'un champ à ne pas remplir ! On le saute carrément ... et on ne peut y entrer ...
nikel ton petit UF
merci
D'où la validation centralisée sur le submitEt avec ce qui convient : on n'attend pas le exit d'un champ à ne pas remplir ! On le saute carrément ... et on ne peut y entrer ...
Donc, une fois que tout est saisi
A mon tour de sortir des "cas"
Comment tu gères la saisie d'une date, si ce n'est sur exit ?
Ouille, Maxence Hubiche,
Tu viens de manquer de prudence....
Je laisse Ousk te répondre (s'il le veut...)
Je ne contrôlerais qu'une chose à l'exit : que le nombre de caractères saisis correspond à celui attendu et rien d'autre ...
Pour le reste : l'utilisateur n'aura même pas à saisir le séparateur, qui s'ecrira seul au fur et à mesure de sa saisie, laquelle ne pourra se faire que dans le format que j'aurai défini et imposé, séparateur compris)... Et la saisie de chaque touche sera contrôlée au fur et à mesure, rendant impossible la saisie d'une date inchoérente, quels que soient le mois , le jour et l'année... et quel que soit les format et séparateur imposés ...
Et ceci (dont ousk te parlera peut-être) est déjà pour moi de l'histoire ancienne....
J'ai maintenant beaucoup mieux et sans me rendre dépendant d'un OCX (datetimepicker, Calendar, etc...) qui ne serait pas de moi.... et les choix de l'utilisateur dans cette fenêtre (qui se place fort opportunément là où il convient) sont directement inscrits dans la textbox concernée, sans code "intermédiaire". Et ce dernier né ne nécessite quant à lui AUCUN contrôle à la sortie !!!!!
La chose est déjà finie sous VB, mais tes remarques me donnent à penser qu'il est inutile que je me casse la tête pour la transposer pour VBA. Plus la peine de me la casser, cette tête, .... puisque le contrôle à l'exit semple être préféré
Eh bien en fait, c'est à toi que je posais la question, donc j'aimerai que ce soit toi qui y réponde...
Et, au vu de ta réponse, j'ajoute ...
donc tu forces une saisie sous la forme 01/01/01
mais si j'ai 01/01/2001 ou encore 01 janvier 2001
Je ne peux plus copier-coller... C'est bien ça ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager