J’ai mis le temps à bien comprendre ton problème et je suis stupéfait de constater que dès qu’on n’utilise pas la fonction Submit de base les champs obligatoires ne sont pas vérifiés, même pas en option…
:mur:
J’ai trouvé divers sujets (ci-joints) sur la question avec différentes façon d’aborder le problème. (Ce sont des captures car soit les sujets soit les forums n’existent plus ou ont été modifiés.)
J’ai fait un exemple à partir du formulaire de contact cité ci-dessus en utilisant la méthode d’Alex (voir son exemple ci-joint : check required fields before print.pdf), c’est celle que je préfère car elle relève plus d’une mise en œuvre dans un vrai processus de production que de l’astuce de forum brute de décoffrage.
D’autre part son principe est simple : plutôt que d’utiliser un long script compliqué* avec des si et des conditions il utilise un script de vérification en action souris-entrée qui affiche une alerte si un champ obligatoire n’est pas rempli.
Dans l’exemple ci-joint (FormContact_obligatoire.pdf) je n’ai eu qu’à rajouter le script en action souris-entrée dans les boutons d’envoi (et à modifier le nom des champs).
Dès que l’alerte est affichée, le bouton n’est plus utilisable tant que l’utilisateur n’a pas cliqué OK dans l’alerte, et donc le bouton ne peut pas déclencher le script d’envoi placé en action souris-relachée. Et ça recommence inlassablement tant que tout n’est pas rempli correctement.
Après que l’utilisateur clique OK le focus (le curseur) se place dans le champ concerné, on pourrait facilement y ajouter un contour rouge, etc.
Dans cet exemple le script limite la quantité de champs obligatoires possibles à 11 pour optimiser sa vitesse d’exécution, mais ce n’est qu’un chiffre à modifier dans le code.
C’est très souple à utiliser parce-que c’est le préfixe du nom du champ qui détermine son caractère obligatoire, et non pas la Propriété du même nom (tant qu’à faire ignorons là jusqu’au bout…).
Et c’est très “user-friendly” parce-que c’est le texte contenu dans l’info-bulle qui apparait comme nom de champ dans l’alerte affichée à l’utilisateur, ce qui permet d’utiliser une désignation plus pertinente que le vrai nom du champ (t.champ.zorglub.3) puisqu’on a droit à tous les caractères (256 maxi).
C’est aussi très facile à utiliser (voir l’exemple d’Alex) avec un bouton “Imprimer”, “Enregistrer”, etc.
:Smiley15:
* Il y a des exemples de scripts ultra-simples ci-joints, mais plus il est simple moins on a de maîtrise sur l’alerte utilisateur, le nom du champ, ce que se passe ensuite, etc.
[attachment deleted by admin]