Les contr=F4les de validation sont bien pratiques pour afficher un messag=
e=20
d'erreur avec quasiment rien comme code =E0 =E9crire.
Toutefois j'ai un souci avec. Le contr=F4le de validation m'affiche un=20
message pour dire qu'une adresse mail n'est pas valide, bon d'accord,=20
mais ce message reste affich=E9 jusqu'=E0 ce que, soit un autre type=20
d'erreur soit commis, soit une adresse mail correcte soit saisie.
=E7a fait que, pour peu que la machine cliente soit un peu lente,=20
l'utilisateur n'a absolument aucun moyen de savoir (sauf bien s=FBr =E0=20
v=E9rifier par lui-m=EAme et auquel cas pourquoi diable n'a-t-il pas sais=
i=20
correctement du premier coup ?) si l'adresse qu'il lui est reproch=E9=20
d'avoir saisie incorrecte est celle qu'il vient de saisir, ou celle=20
qu'il a propos=E9e la fois pr=E9c=E9dente qu'il a cliqu=E9 sur le bouton.=
Il n'a=20
qu'=E0 attendre pour voir si il va se passer quelque chose.
Ainsi donc, si il se confirme que ce n'est pas d=E9j=E0 pr=E9vu et que ce=
=20
n'est pas moi qui ai mal mis en =9Cuvre les contr=F4les de validation, je=
=20
voudrais cr=E9er un script onchange sur le contr=F4le TextBox, =E0 ex=E9c=
uter en=20
local bien entendu, qui rende invisible le contr=F4le ValidationSummary. =
Voil=E0 qui ferait dispara=EEtre le message de l'=E9cran d=E8s qu'on en=20
tiendrait compte pour modifier le texte, et ainsi lorsque l'utilisateur=20
verrait r=E9appara=EEtre le message il saurait que c'est au sujet de sa=20
nouvelle saisie.
Or, pour faire ceci, je rencontre une incoh=E9rence, =E0 moins encore une=
=20
fois que ce soit moi qui aie des trucs mal branch=E9s dans la t=EAte ...
Le contr=F4le TextBox a une propri=E9t=E9 obligatoire runat, mais cette=20
propri=E9t=E9 ne peut avoir qu'une valeur possible, server. Alors je me=20
demande bien, puisque la plateforme sait d=E9j=E0 o=F9 exactement elle ve=
ut=20
ex=E9cuter ce script et quelle valeur elle accorde au choix du programmeu=
r=20
=E0 ce sujet, pourquoi diable elle impose =E0 celui-ci de confirmer ce ch=
oix=20
qui ne lui convient pas.
En effet, soit on met un CauseValidation au TextBox et =E0 chaque fois=20
qu'on va saisir un caract=E8re il faudra attendre le PostBack, voil=E0 qu=
i=20
va =EAtre g=E9nial pour les gens connect=E9s en RTC avec un modem 16 bps,=
soit=20
on ne le met pas et le runat server ne sera ex=E9cut=E9 que lorsqu'on=20
cliquera sur le bouton, et =E0 ce moment le message suivant sera affich=E9=
,=20
donc il vaut autant ne rien faire.
J'ai l'impression que j'ai d=FB prendre un truc par le mauvais bout, mais=
=20
quoi ?
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
Gilles TOURREAU - MVP C#
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de postback,, vous devez programmer par vous même le code en JavaScript...
Cordialement
-- Gilles TOURREAU - MVP C# E-Mail : Site Web : http://gilles.tourreau.fr
Société P.O.S - Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
"Gloops" a écrit dans le message de groupe de discussion :
Bonjour tout le monde,
Les contrôles de validation sont bien pratiques pour afficher un message d'erreur avec quasiment rien comme code à écrire.
Toutefois j'ai un souci avec. Le contrôle de validation m'affiche un message pour dire qu'une adresse mail n'est pas valide, bon d'accord, mais ce message reste affiché jusqu'à ce que, soit un autre type d'erreur soit commis, soit une adresse mail correcte soit saisie.
ça fait que, pour peu que la machine cliente soit un peu lente, l'utilisateur n'a absolument aucun moyen de savoir (sauf bien sûr à vérifier par lui-même et auquel cas pourquoi diable n'a-t-il pas saisi correctement du premier coup ?) si l'adresse qu'il lui est reproché d'avoir saisie incorrecte est celle qu'il vient de saisir, ou celle qu'il a proposée la fois précédente qu'il a cliqué sur le bouton. Il n'a qu'à attendre pour voir si il va se passer quelque chose.
Ainsi donc, si il se confirme que ce n'est pas déjà prévu et que ce n'est pas moi qui ai mal mis en œuvre les contrôles de validation, je voudrais créer un script onchange sur le contrôle TextBox, à exécuter en local bien entendu, qui rende invisible le contrôle ValidationSummary. Voilà qui ferait disparaître le message de l'écran dès qu'on en tiendrait compte pour modifier le texte, et ainsi lorsque l'utilisateur verrait réapparaître le message il saurait que c'est au sujet de sa nouvelle saisie.
Or, pour faire ceci, je rencontre une incohérence, à moins encore une fois que ce soit moi qui aie des trucs mal branchés dans la tête ... Le contrôle TextBox a une propriété obligatoire runat, mais cette propriété ne peut avoir qu'une valeur possible, server. Alors je me demande bien, puisque la plateforme sait déjà où exactement elle veut exécuter ce script et quelle valeur elle accorde au choix du programmeur à ce sujet, pourquoi diable elle impose à celui-ci de confirmer ce choix qui ne lui convient pas.
En effet, soit on met un CauseValidation au TextBox et à chaque fois qu'on va saisir un caractère il faudra attendre le PostBack, voilà qui va être génial pour les gens connectés en RTC avec un modem 16 bps, soit on ne le met pas et le runat server ne sera exécuté que lorsqu'on cliquera sur le bouton, et à ce moment le message suivant sera affiché, donc il vaut autant ne rien faire.
J'ai l'impression que j'ai dû prendre un truc par le mauvais bout, mais quoi ?
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de postback,,
vous devez programmer par vous même le code en JavaScript...
Cordialement
--
Gilles TOURREAU - MVP C#
E-Mail : gilles.tourreau@pos.fr
Site Web : http://gilles.tourreau.fr
Société P.O.S - Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de groupe de
discussion : euCpB7aHKHA.3928@TK2MSFTNGP04.phx.gbl...
Bonjour tout le monde,
Les contrôles de validation sont bien pratiques pour afficher un message
d'erreur avec quasiment rien comme code à écrire.
Toutefois j'ai un souci avec. Le contrôle de validation m'affiche un
message pour dire qu'une adresse mail n'est pas valide, bon d'accord, mais
ce message reste affiché jusqu'à ce que, soit un autre type d'erreur soit
commis, soit une adresse mail correcte soit saisie.
ça fait que, pour peu que la machine cliente soit un peu lente,
l'utilisateur n'a absolument aucun moyen de savoir (sauf bien sûr à
vérifier par lui-même et auquel cas pourquoi diable n'a-t-il pas saisi
correctement du premier coup ?) si l'adresse qu'il lui est reproché
d'avoir saisie incorrecte est celle qu'il vient de saisir, ou celle qu'il
a proposée la fois précédente qu'il a cliqué sur le bouton. Il n'a qu'à
attendre pour voir si il va se passer quelque chose.
Ainsi donc, si il se confirme que ce n'est pas déjà prévu et que ce n'est
pas moi qui ai mal mis en œuvre les contrôles de validation, je voudrais
créer un script onchange sur le contrôle TextBox, à exécuter en local bien
entendu, qui rende invisible le contrôle ValidationSummary. Voilà qui
ferait disparaître le message de l'écran dès qu'on en tiendrait compte
pour modifier le texte, et ainsi lorsque l'utilisateur verrait
réapparaître le message il saurait que c'est au sujet de sa nouvelle
saisie.
Or, pour faire ceci, je rencontre une incohérence, à moins encore une fois
que ce soit moi qui aie des trucs mal branchés dans la tête ...
Le contrôle TextBox a une propriété obligatoire runat, mais cette
propriété ne peut avoir qu'une valeur possible, server. Alors je me
demande bien, puisque la plateforme sait déjà où exactement elle veut
exécuter ce script et quelle valeur elle accorde au choix du programmeur à
ce sujet, pourquoi diable elle impose à celui-ci de confirmer ce choix qui
ne lui convient pas.
En effet, soit on met un CauseValidation au TextBox et à chaque fois qu'on
va saisir un caractère il faudra attendre le PostBack, voilà qui va être
génial pour les gens connectés en RTC avec un modem 16 bps, soit on ne le
met pas et le runat server ne sera exécuté que lorsqu'on cliquera sur le
bouton, et à ce moment le message suivant sera affiché, donc il vaut
autant ne rien faire.
J'ai l'impression que j'ai dû prendre un truc par le mauvais bout, mais
quoi ?
Pour faire ce genre de contrôle de validation sans réaliser de postback,, vous devez programmer par vous même le code en JavaScript...
Cordialement
-- Gilles TOURREAU - MVP C# E-Mail : Site Web : http://gilles.tourreau.fr
Société P.O.S - Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
"Gloops" a écrit dans le message de groupe de discussion :
Bonjour tout le monde,
Les contrôles de validation sont bien pratiques pour afficher un message d'erreur avec quasiment rien comme code à écrire.
Toutefois j'ai un souci avec. Le contrôle de validation m'affiche un message pour dire qu'une adresse mail n'est pas valide, bon d'accord, mais ce message reste affiché jusqu'à ce que, soit un autre type d'erreur soit commis, soit une adresse mail correcte soit saisie.
ça fait que, pour peu que la machine cliente soit un peu lente, l'utilisateur n'a absolument aucun moyen de savoir (sauf bien sûr à vérifier par lui-même et auquel cas pourquoi diable n'a-t-il pas saisi correctement du premier coup ?) si l'adresse qu'il lui est reproché d'avoir saisie incorrecte est celle qu'il vient de saisir, ou celle qu'il a proposée la fois précédente qu'il a cliqué sur le bouton. Il n'a qu'à attendre pour voir si il va se passer quelque chose.
Ainsi donc, si il se confirme que ce n'est pas déjà prévu et que ce n'est pas moi qui ai mal mis en œuvre les contrôles de validation, je voudrais créer un script onchange sur le contrôle TextBox, à exécuter en local bien entendu, qui rende invisible le contrôle ValidationSummary. Voilà qui ferait disparaître le message de l'écran dès qu'on en tiendrait compte pour modifier le texte, et ainsi lorsque l'utilisateur verrait réapparaître le message il saurait que c'est au sujet de sa nouvelle saisie.
Or, pour faire ceci, je rencontre une incohérence, à moins encore une fois que ce soit moi qui aie des trucs mal branchés dans la tête ... Le contrôle TextBox a une propriété obligatoire runat, mais cette propriété ne peut avoir qu'une valeur possible, server. Alors je me demande bien, puisque la plateforme sait déjà où exactement elle veut exécuter ce script et quelle valeur elle accorde au choix du programmeur à ce sujet, pourquoi diable elle impose à celui-ci de confirmer ce choix qui ne lui convient pas.
En effet, soit on met un CauseValidation au TextBox et à chaque fois qu'on va saisir un caractère il faudra attendre le PostBack, voilà qui va être génial pour les gens connectés en RTC avec un modem 16 bps, soit on ne le met pas et le runat server ne sera exécuté que lorsqu'on cliquera sur le bouton, et à ce moment le message suivant sera affiché, donc il vaut autant ne rien faire.
J'ai l'impression que j'ai dû prendre un truc par le mauvais bout, mais quoi ?
Gloops
Gilles TOURREAU - MVP C# a écrit, le 22/08/2009 21:40 :
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de postback,, vous devez programmer par vous même le code en JavaScript. ..
Cordialement
Bjr,
A vrai dire, oui, c'est un peu ça que j'ai essayé de faire. C'est un peu pour ça que le runat=serveur pour le TextBox m'embête un peu. Y a-t -il moyen de lui faire entendre raison ?
Gilles TOURREAU - MVP C# a écrit, le 22/08/2009 21:40 :
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de
postback,, vous devez programmer par vous même le code en JavaScript. ..
Cordialement
Bjr,
A vrai dire, oui, c'est un peu ça que j'ai essayé de faire. C'est un peu
pour ça que le runat=serveur pour le TextBox m'embête un peu. Y a-t -il
moyen de lui faire entendre raison ?
Gilles TOURREAU - MVP C# a écrit, le 22/08/2009 21:40 :
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de postback,, vous devez programmer par vous même le code en JavaScript. ..
Cordialement
Bjr,
A vrai dire, oui, c'est un peu ça que j'ai essayé de faire. C'est un peu pour ça que le runat=serveur pour le TextBox m'embête un peu. Y a-t -il moyen de lui faire entendre raison ?
Gloops
Bonjour,
Maintenant que je commence à être opérationnel avec la réception de mails, je reviens sur la validation.
Apparemment ça risque de prendre un sacré bout de temps de farfouille r dans les sous-contrôles du validateur pour rendre invisible le message, sans empêcher qu'une nouvelle erreur le rende de nouveau visible.
En revanche, le validateur présente les propriétés ShowMessageBox e t ShowSummary. En les mettant respectivement à true et false, on obtient quelque chose qui, bien que me paraissant moins esthétique, est au moin s fonctionnel, puisque le message d'erreur, comme le laisse entendre le nom de la propriété, apparaît dans une boîte de message, que l'utilisateur est invité à refermer après avoir lu.
Jusqu'à ce que quelqu'un m'indique quoi faire pour exploiter le ShowSummary, je vais partir du principe que ce message qui reste visible jusqu'à en faire apparaître un autre ou avoir réalisé une saisie correcte est un bug du Validator, et puisqu'un autre mode permet d'obtenir un résultat opérationnel, je vais utiliser cet autre mode, tant pis pour l'esthétique.
J'ai par ailleurs une réponse pour exécuter un script en mode local : dans la boîte à outils, on trouve dans la catégorie Standard un con trôle Button (celui que j'utilise avec le Validator) et plus bas dans la catégorie HTML un contrôle "Input (button)". Le premier s'exécute s ur le serveur, le deuxième en local. Je vais en rester là jusqu'à ce que quelqu'un me trouve un contrôle qui accepte de faire les deux. _____________________________________ Gloops a écrit, le 15/08/2009 15:46 :
Bonjour tout le monde,
Les contrôles de validation sont bien pratiques pour afficher un mess age d'erreur avec quasiment rien comme code à écrire.
Toutefois j'ai un souci avec. Le contrôle de validation m'affiche un message pour dire qu'une adresse mail n'est pas valide, bon d'accord, mais ce message reste affiché jusqu'à ce que, soit un autre type d'erreur soit commis, soit une adresse mail correcte soit saisie.
ça fait que, pour peu que la machine cliente soit un peu lente, l'utilisateur n'a absolument aucun moyen de savoir (sauf bien sûr à vérifier par lui-même et auquel cas pourquoi diable n'a-t-il pas sa isi correctement du premier coup ?) si l'adresse qu'il lui est reproché d'avoir saisie incorrecte est celle qu'il vient de saisir, ou celle qu'il a proposée la fois précédente qu'il a cliqué sur le bouto n. Il n'a qu'à attendre pour voir si il va se passer quelque chose.
Ainsi donc, si il se confirme que ce n'est pas déjà prévu et que ce n'est pas moi qui ai mal mis en uvre les contrôles de validation, je voudrais créer un script onchange sur le contrôle TextBox, à exé cuter en local bien entendu, qui rende invisible le contrôle ValidationSummary . Voilà qui ferait disparaître le message de l'écran dès qu'on en tiendrait compte pour modifier le texte, et ainsi lorsque l'utilisateur verrait réapparaître le message il saurait que c'est au sujet de sa nouvelle saisie.
Or, pour faire ceci, je rencontre une incohérence, à moins encore u ne fois que ce soit moi qui aie des trucs mal branchés dans la tête .. . Le contrôle TextBox a une propriété obligatoire runat, mais cette propriété ne peut avoir qu'une valeur possible, server. Alors je me demande bien, puisque la plateforme sait déjà où exactement elle veut exécuter ce script et quelle valeur elle accorde au choix du programm eur à ce sujet, pourquoi diable elle impose à celui-ci de confirmer ce choix qui ne lui convient pas.
En effet, soit on met un CauseValidation au TextBox et à chaque fois qu'on va saisir un caractère il faudra attendre le PostBack, voilà qui va être génial pour les gens connectés en RTC avec un modem 16 bp s, soit on ne le met pas et le runat server ne sera exécuté que lorsqu'on cliquera sur le bouton, et à ce moment le message suivant sera affich é, donc il vaut autant ne rien faire.
J'ai l'impression que j'ai dû prendre un truc par le mauvais bout, ma is quoi ?
Bonjour,
Maintenant que je commence à être opérationnel avec la réception de
mails, je reviens sur la validation.
Apparemment ça risque de prendre un sacré bout de temps de farfouille r
dans les sous-contrôles du validateur pour rendre invisible le message,
sans empêcher qu'une nouvelle erreur le rende de nouveau visible.
En revanche, le validateur présente les propriétés ShowMessageBox e t
ShowSummary. En les mettant respectivement à true et false, on obtient
quelque chose qui, bien que me paraissant moins esthétique, est au moin s
fonctionnel, puisque le message d'erreur, comme le laisse entendre le
nom de la propriété, apparaît dans une boîte de message, que
l'utilisateur est invité à refermer après avoir lu.
Jusqu'à ce que quelqu'un m'indique quoi faire pour exploiter le
ShowSummary, je vais partir du principe que ce message qui reste visible
jusqu'à en faire apparaître un autre ou avoir réalisé une saisie
correcte est un bug du Validator, et puisqu'un autre mode permet
d'obtenir un résultat opérationnel, je vais utiliser cet autre mode,
tant pis pour l'esthétique.
J'ai par ailleurs une réponse pour exécuter un script en mode local :
dans la boîte à outils, on trouve dans la catégorie Standard un con trôle
Button (celui que j'utilise avec le Validator) et plus bas dans la
catégorie HTML un contrôle "Input (button)". Le premier s'exécute s ur le
serveur, le deuxième en local. Je vais en rester là jusqu'à ce que
quelqu'un me trouve un contrôle qui accepte de faire les deux.
_____________________________________
Gloops a écrit, le 15/08/2009 15:46 :
Bonjour tout le monde,
Les contrôles de validation sont bien pratiques pour afficher un mess age
d'erreur avec quasiment rien comme code à écrire.
Toutefois j'ai un souci avec. Le contrôle de validation m'affiche un
message pour dire qu'une adresse mail n'est pas valide, bon d'accord,
mais ce message reste affiché jusqu'à ce que, soit un autre type
d'erreur soit commis, soit une adresse mail correcte soit saisie.
ça fait que, pour peu que la machine cliente soit un peu lente,
l'utilisateur n'a absolument aucun moyen de savoir (sauf bien sûr à
vérifier par lui-même et auquel cas pourquoi diable n'a-t-il pas sa isi
correctement du premier coup ?) si l'adresse qu'il lui est reproché
d'avoir saisie incorrecte est celle qu'il vient de saisir, ou celle
qu'il a proposée la fois précédente qu'il a cliqué sur le bouto n. Il n'a
qu'à attendre pour voir si il va se passer quelque chose.
Ainsi donc, si il se confirme que ce n'est pas déjà prévu et que ce
n'est pas moi qui ai mal mis en uvre les contrôles de validation, je
voudrais créer un script onchange sur le contrôle TextBox, à exé cuter en
local bien entendu, qui rende invisible le contrôle ValidationSummary .
Voilà qui ferait disparaître le message de l'écran dès qu'on en
tiendrait compte pour modifier le texte, et ainsi lorsque l'utilisateur
verrait réapparaître le message il saurait que c'est au sujet de sa
nouvelle saisie.
Or, pour faire ceci, je rencontre une incohérence, à moins encore u ne
fois que ce soit moi qui aie des trucs mal branchés dans la tête .. .
Le contrôle TextBox a une propriété obligatoire runat, mais cette
propriété ne peut avoir qu'une valeur possible, server. Alors je me
demande bien, puisque la plateforme sait déjà où exactement elle veut
exécuter ce script et quelle valeur elle accorde au choix du programm eur
à ce sujet, pourquoi diable elle impose à celui-ci de confirmer ce choix
qui ne lui convient pas.
En effet, soit on met un CauseValidation au TextBox et à chaque fois
qu'on va saisir un caractère il faudra attendre le PostBack, voilà qui
va être génial pour les gens connectés en RTC avec un modem 16 bp s, soit
on ne le met pas et le runat server ne sera exécuté que lorsqu'on
cliquera sur le bouton, et à ce moment le message suivant sera affich é,
donc il vaut autant ne rien faire.
J'ai l'impression que j'ai dû prendre un truc par le mauvais bout, ma is
quoi ?
Maintenant que je commence à être opérationnel avec la réception de mails, je reviens sur la validation.
Apparemment ça risque de prendre un sacré bout de temps de farfouille r dans les sous-contrôles du validateur pour rendre invisible le message, sans empêcher qu'une nouvelle erreur le rende de nouveau visible.
En revanche, le validateur présente les propriétés ShowMessageBox e t ShowSummary. En les mettant respectivement à true et false, on obtient quelque chose qui, bien que me paraissant moins esthétique, est au moin s fonctionnel, puisque le message d'erreur, comme le laisse entendre le nom de la propriété, apparaît dans une boîte de message, que l'utilisateur est invité à refermer après avoir lu.
Jusqu'à ce que quelqu'un m'indique quoi faire pour exploiter le ShowSummary, je vais partir du principe que ce message qui reste visible jusqu'à en faire apparaître un autre ou avoir réalisé une saisie correcte est un bug du Validator, et puisqu'un autre mode permet d'obtenir un résultat opérationnel, je vais utiliser cet autre mode, tant pis pour l'esthétique.
J'ai par ailleurs une réponse pour exécuter un script en mode local : dans la boîte à outils, on trouve dans la catégorie Standard un con trôle Button (celui que j'utilise avec le Validator) et plus bas dans la catégorie HTML un contrôle "Input (button)". Le premier s'exécute s ur le serveur, le deuxième en local. Je vais en rester là jusqu'à ce que quelqu'un me trouve un contrôle qui accepte de faire les deux. _____________________________________ Gloops a écrit, le 15/08/2009 15:46 :
Bonjour tout le monde,
Les contrôles de validation sont bien pratiques pour afficher un mess age d'erreur avec quasiment rien comme code à écrire.
Toutefois j'ai un souci avec. Le contrôle de validation m'affiche un message pour dire qu'une adresse mail n'est pas valide, bon d'accord, mais ce message reste affiché jusqu'à ce que, soit un autre type d'erreur soit commis, soit une adresse mail correcte soit saisie.
ça fait que, pour peu que la machine cliente soit un peu lente, l'utilisateur n'a absolument aucun moyen de savoir (sauf bien sûr à vérifier par lui-même et auquel cas pourquoi diable n'a-t-il pas sa isi correctement du premier coup ?) si l'adresse qu'il lui est reproché d'avoir saisie incorrecte est celle qu'il vient de saisir, ou celle qu'il a proposée la fois précédente qu'il a cliqué sur le bouto n. Il n'a qu'à attendre pour voir si il va se passer quelque chose.
Ainsi donc, si il se confirme que ce n'est pas déjà prévu et que ce n'est pas moi qui ai mal mis en uvre les contrôles de validation, je voudrais créer un script onchange sur le contrôle TextBox, à exé cuter en local bien entendu, qui rende invisible le contrôle ValidationSummary . Voilà qui ferait disparaître le message de l'écran dès qu'on en tiendrait compte pour modifier le texte, et ainsi lorsque l'utilisateur verrait réapparaître le message il saurait que c'est au sujet de sa nouvelle saisie.
Or, pour faire ceci, je rencontre une incohérence, à moins encore u ne fois que ce soit moi qui aie des trucs mal branchés dans la tête .. . Le contrôle TextBox a une propriété obligatoire runat, mais cette propriété ne peut avoir qu'une valeur possible, server. Alors je me demande bien, puisque la plateforme sait déjà où exactement elle veut exécuter ce script et quelle valeur elle accorde au choix du programm eur à ce sujet, pourquoi diable elle impose à celui-ci de confirmer ce choix qui ne lui convient pas.
En effet, soit on met un CauseValidation au TextBox et à chaque fois qu'on va saisir un caractère il faudra attendre le PostBack, voilà qui va être génial pour les gens connectés en RTC avec un modem 16 bp s, soit on ne le met pas et le runat server ne sera exécuté que lorsqu'on cliquera sur le bouton, et à ce moment le message suivant sera affich é, donc il vaut autant ne rien faire.
J'ai l'impression que j'ai dû prendre un truc par le mauvais bout, ma is quoi ?
Gilles TOURREAU
Bonjour,
La propriété runat="server" est obligatoire pour indiquer à ASP .NET que la balise correspond à un contrôle qui sera crée et chargé dans l'arborescence des contrôles d'ASP .NET afin que vous puissiez manipuler ses propriétés en C#.
Est-ce que cela répond à votre question ?
Cordialement
-- Gilles TOURREAU - MVP C# E-Mail : Site Web : http://gilles.tourreau.fr
Société P.O.S - Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
"Gloops" a écrit dans le message de groupe de discussion :
Gilles TOURREAU - MVP C# a écrit, le 22/08/2009 21:40 :
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de postback,, vous devez programmer par vous même le code en JavaScript...
Cordialement
Bjr,
A vrai dire, oui, c'est un peu ça que j'ai essayé de faire. C'est un peu pour ça que le runat=serveur pour le TextBox m'embête un peu. Y a-t-il moyen de lui faire entendre raison ?
Bonjour,
La propriété runat="server" est obligatoire pour indiquer à ASP .NET que la
balise correspond à un contrôle qui sera crée et chargé dans l'arborescence
des contrôles d'ASP .NET afin que vous puissiez manipuler ses propriétés en
C#.
Est-ce que cela répond à votre question ?
Cordialement
--
Gilles TOURREAU - MVP C#
E-Mail : gilles.tourreau@pos.fr
Site Web : http://gilles.tourreau.fr
Société P.O.S - Le spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de groupe de
discussion : O8aGHdDJKHA.5984@TK2MSFTNGP05.phx.gbl...
Gilles TOURREAU - MVP C# a écrit, le 22/08/2009 21:40 :
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de postback,,
vous devez programmer par vous même le code en JavaScript...
Cordialement
Bjr,
A vrai dire, oui, c'est un peu ça que j'ai essayé de faire. C'est un peu
pour ça que le runat=serveur pour le TextBox m'embête un peu. Y a-t-il
moyen de lui faire entendre raison ?
La propriété runat="server" est obligatoire pour indiquer à ASP .NET que la balise correspond à un contrôle qui sera crée et chargé dans l'arborescence des contrôles d'ASP .NET afin que vous puissiez manipuler ses propriétés en C#.
Est-ce que cela répond à votre question ?
Cordialement
-- Gilles TOURREAU - MVP C# E-Mail : Site Web : http://gilles.tourreau.fr
Société P.O.S - Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
"Gloops" a écrit dans le message de groupe de discussion :
Gilles TOURREAU - MVP C# a écrit, le 22/08/2009 21:40 :
Bonjour,
Pour faire ce genre de contrôle de validation sans réaliser de postback,, vous devez programmer par vous même le code en JavaScript...
Cordialement
Bjr,
A vrai dire, oui, c'est un peu ça que j'ai essayé de faire. C'est un peu pour ça que le runat=serveur pour le TextBox m'embête un peu. Y a-t-il moyen de lui faire entendre raison ?
Gloops
Gilles TOURREAU a écrit, le 12/09/2009 10:50 :
Bonjour,
La propriété runat="server" est obligatoire pour indiquer à ASP .NET que la balise correspond à un contrôle qui sera crée et chargé dans l'arborescence des contrôles d'ASP .NET afin que vous puissiez manipu ler ses propriétés en C#.
C'est un petit peu ça qui me contrarie, justement, et du coup j'en arrive à me dire que je n'ai pas su poser ma question. Merci tout de même d'avoir tenté de me répondre.
J'ai découvert depuis que si on veut exécuter du JavaScript écrit m aison sur la machine cliente lors de la modification du contenu d'une zone de texte, il y a lieu d'utiliser non pas un TextBox asp, de la catégorie Standard de la boîte à outils Visual Studio, mais un contrôle Input (Text) qu'on trouve plus bas dans la catégorie HTML. Toutefois ce faisant, on renonce au bénéfice des contrôles de validation.
Donc, finalement, le mieux que j'aie su faire avec le contrôle de validation, comme je le dis ailleurs dans ce fil, consiste à jouer avec les propriétés ShowMessageBox et ShowSummary du ValidationSummary, po ur afficher le message d'erreur non sur la page, mais dans une boîte de dialogue. C'est moins beau, mais fonctionnellement c'est clair. Je n'ai pas testé sur tous les navigateurs existants il est vrai.
Autrement c'est vrai qu'on peut réécrire toute la boutique soi-même , mais alors autant coder avec le bloc-notes :)
Par ailleurs au cours d'une séance de mise en page, j'ai pu me rendre compte que sur un contrôle de validation comme par exemple RequiredFieldValidator, la propriété Visible signifie ce qu'instinctivement j'aurais eu tendance à appeler Enabled. Si on met False, le test n'est pas effectué, et le ControlToValidate (TextBox par exemple) peut très bien être validé vide. Dans la réalité, avec Visible=True, le message devient visible dans le ValidationSummary selo n les propriétés de celui-ci et la valeur saisie. Ce qui fait que, si o n veut, dans les propriétés du RequiredFieldValidator, le mot Visible était disponible pour autre chose (ceci dit, il faut suivre :) ).
Par ailleurs, si la petite flèche rouge n'apporte rien, rien n'empêch e de placer le contrôle de validation, avec Visible=True, dans une cell ule de tableau non visible. Il sera opérationnel, mais sans trace à l'é cran devant le contrôle validé. Concrètement, c'est plutôt dans les ca s où il n'y a qu'une zone de texte à saisir qu'on sera tenté de faire comme ç a : là, l'utilisateur se doute bien que si il a commis une erreur, c'est là-dedans (enfin du moins, je l'espère ; enfin sauf à avoir placé la zone de texte en haut à gauche de la page et le bouton en bas à droit e, ou l'inverse ;) ).
Je crois qu'effectivement créer un événement qui se déclenche en local sur la machine cliente à la modification d'un contrôle asp tient de l a gymnastique de haut vol, du fait que ce n'est pas prévu comme ça, et du coup vraisemblablement on sortirait de ce qu'on appelle code managé. Peut-être une mise à jour corrigera-t-elle ce problème de message q ui reste affiché une fois qu'il n'est plus d'actualité ? Je me demande si même on pourrait créer un nouveau contrôle de validation en ce sens. Il faudrait qu'il puisse exploiter la modification du contrôle à valider, donc, retour à la case départ . Ou alors, exploiter un changement de focus ? J'avoue que pour le moment, je vais me contenter de laisser la question ouverte.
(A propos de l'usage de contrôles classiques à la place de contrôle s asp, on observe la même chose lors de la création d'une page maître sse, si les ContentPlaceHolders doivent être placés dans un tableau : il n e faut surtout pas utiliser un tableau ASP, ou il sera ignoré dans la mis e en page, mais il faut insérer les ContentPlaceHolders dans des balises HTML classiques (<TABLE><TR><TD></TD></TR></TABLE>). Celles-ci bénéficient d'ailleurs du contrôle de syntaxe avec l'Intellisense. Il semble que ce soit plus commode pour faire ça d'afficher en mode Source qu'en mode Design, si tant est d'ailleurs qu'on puisse faire autrement.)
Gilles TOURREAU a écrit, le 12/09/2009 10:50 :
Bonjour,
La propriété runat="server" est obligatoire pour indiquer à ASP .NET que
la balise correspond à un contrôle qui sera crée et chargé dans
l'arborescence des contrôles d'ASP .NET afin que vous puissiez manipu ler
ses propriétés en C#.
C'est un petit peu ça qui me contrarie, justement, et du coup j'en
arrive à me dire que je n'ai pas su poser ma question. Merci tout de
même d'avoir tenté de me répondre.
J'ai découvert depuis que si on veut exécuter du JavaScript écrit m aison
sur la machine cliente lors de la modification du contenu d'une zone de
texte, il y a lieu d'utiliser non pas un TextBox asp, de la catégorie
Standard de la boîte à outils Visual Studio, mais un contrôle Input
(Text) qu'on trouve plus bas dans la catégorie HTML. Toutefois ce
faisant, on renonce au bénéfice des contrôles de validation.
Donc, finalement, le mieux que j'aie su faire avec le contrôle de
validation, comme je le dis ailleurs dans ce fil, consiste à jouer avec
les propriétés ShowMessageBox et ShowSummary du ValidationSummary, po ur
afficher le message d'erreur non sur la page, mais dans une boîte de
dialogue. C'est moins beau, mais fonctionnellement c'est clair. Je n'ai
pas testé sur tous les navigateurs existants il est vrai.
Autrement c'est vrai qu'on peut réécrire toute la boutique soi-même ,
mais alors autant coder avec le bloc-notes :)
Par ailleurs au cours d'une séance de mise en page, j'ai pu me rendre
compte que sur un contrôle de validation comme par exemple
RequiredFieldValidator, la propriété Visible signifie ce
qu'instinctivement j'aurais eu tendance à appeler Enabled. Si on met
False, le test n'est pas effectué, et le ControlToValidate (TextBox par
exemple) peut très bien être validé vide. Dans la réalité, avec
Visible=True, le message devient visible dans le ValidationSummary selo n
les propriétés de celui-ci et la valeur saisie. Ce qui fait que, si o n
veut, dans les propriétés du RequiredFieldValidator, le mot Visible
était disponible pour autre chose (ceci dit, il faut suivre :) ).
Par ailleurs, si la petite flèche rouge n'apporte rien, rien n'empêch e
de placer le contrôle de validation, avec Visible=True, dans une cell ule
de tableau non visible. Il sera opérationnel, mais sans trace à l'é cran
devant le contrôle validé. Concrètement, c'est plutôt dans les ca s où il
n'y a qu'une zone de texte à saisir qu'on sera tenté de faire comme ç a :
là, l'utilisateur se doute bien que si il a commis une erreur, c'est
là-dedans (enfin du moins, je l'espère ; enfin sauf à avoir placé la
zone de texte en haut à gauche de la page et le bouton en bas à droit e,
ou l'inverse ;) ).
Je crois qu'effectivement créer un événement qui se déclenche en local
sur la machine cliente à la modification d'un contrôle asp tient de l a
gymnastique de haut vol, du fait que ce n'est pas prévu comme ça, et du
coup vraisemblablement on sortirait de ce qu'on appelle code managé.
Peut-être une mise à jour corrigera-t-elle ce problème de message q ui
reste affiché une fois qu'il n'est plus d'actualité ?
Je me demande si même on pourrait créer un nouveau contrôle de
validation en ce sens. Il faudrait qu'il puisse exploiter la
modification du contrôle à valider, donc, retour à la case départ . Ou
alors, exploiter un changement de focus ? J'avoue que pour le moment, je
vais me contenter de laisser la question ouverte.
(A propos de l'usage de contrôles classiques à la place de contrôle s
asp, on observe la même chose lors de la création d'une page maître sse,
si les ContentPlaceHolders doivent être placés dans un tableau : il n e
faut surtout pas utiliser un tableau ASP, ou il sera ignoré dans la mis e
en page, mais il faut insérer les ContentPlaceHolders dans des balises
HTML classiques (<TABLE><TR><TD></TD></TR></TABLE>). Celles-ci
bénéficient d'ailleurs du contrôle de syntaxe avec l'Intellisense. Il
semble que ce soit plus commode pour faire ça d'afficher en mode Source
qu'en mode Design, si tant est d'ailleurs qu'on puisse faire autrement.)
La propriété runat="server" est obligatoire pour indiquer à ASP .NET que la balise correspond à un contrôle qui sera crée et chargé dans l'arborescence des contrôles d'ASP .NET afin que vous puissiez manipu ler ses propriétés en C#.
C'est un petit peu ça qui me contrarie, justement, et du coup j'en arrive à me dire que je n'ai pas su poser ma question. Merci tout de même d'avoir tenté de me répondre.
J'ai découvert depuis que si on veut exécuter du JavaScript écrit m aison sur la machine cliente lors de la modification du contenu d'une zone de texte, il y a lieu d'utiliser non pas un TextBox asp, de la catégorie Standard de la boîte à outils Visual Studio, mais un contrôle Input (Text) qu'on trouve plus bas dans la catégorie HTML. Toutefois ce faisant, on renonce au bénéfice des contrôles de validation.
Donc, finalement, le mieux que j'aie su faire avec le contrôle de validation, comme je le dis ailleurs dans ce fil, consiste à jouer avec les propriétés ShowMessageBox et ShowSummary du ValidationSummary, po ur afficher le message d'erreur non sur la page, mais dans une boîte de dialogue. C'est moins beau, mais fonctionnellement c'est clair. Je n'ai pas testé sur tous les navigateurs existants il est vrai.
Autrement c'est vrai qu'on peut réécrire toute la boutique soi-même , mais alors autant coder avec le bloc-notes :)
Par ailleurs au cours d'une séance de mise en page, j'ai pu me rendre compte que sur un contrôle de validation comme par exemple RequiredFieldValidator, la propriété Visible signifie ce qu'instinctivement j'aurais eu tendance à appeler Enabled. Si on met False, le test n'est pas effectué, et le ControlToValidate (TextBox par exemple) peut très bien être validé vide. Dans la réalité, avec Visible=True, le message devient visible dans le ValidationSummary selo n les propriétés de celui-ci et la valeur saisie. Ce qui fait que, si o n veut, dans les propriétés du RequiredFieldValidator, le mot Visible était disponible pour autre chose (ceci dit, il faut suivre :) ).
Par ailleurs, si la petite flèche rouge n'apporte rien, rien n'empêch e de placer le contrôle de validation, avec Visible=True, dans une cell ule de tableau non visible. Il sera opérationnel, mais sans trace à l'é cran devant le contrôle validé. Concrètement, c'est plutôt dans les ca s où il n'y a qu'une zone de texte à saisir qu'on sera tenté de faire comme ç a : là, l'utilisateur se doute bien que si il a commis une erreur, c'est là-dedans (enfin du moins, je l'espère ; enfin sauf à avoir placé la zone de texte en haut à gauche de la page et le bouton en bas à droit e, ou l'inverse ;) ).
Je crois qu'effectivement créer un événement qui se déclenche en local sur la machine cliente à la modification d'un contrôle asp tient de l a gymnastique de haut vol, du fait que ce n'est pas prévu comme ça, et du coup vraisemblablement on sortirait de ce qu'on appelle code managé. Peut-être une mise à jour corrigera-t-elle ce problème de message q ui reste affiché une fois qu'il n'est plus d'actualité ? Je me demande si même on pourrait créer un nouveau contrôle de validation en ce sens. Il faudrait qu'il puisse exploiter la modification du contrôle à valider, donc, retour à la case départ . Ou alors, exploiter un changement de focus ? J'avoue que pour le moment, je vais me contenter de laisser la question ouverte.
(A propos de l'usage de contrôles classiques à la place de contrôle s asp, on observe la même chose lors de la création d'une page maître sse, si les ContentPlaceHolders doivent être placés dans un tableau : il n e faut surtout pas utiliser un tableau ASP, ou il sera ignoré dans la mis e en page, mais il faut insérer les ContentPlaceHolders dans des balises HTML classiques (<TABLE><TR><TD></TD></TR></TABLE>). Celles-ci bénéficient d'ailleurs du contrôle de syntaxe avec l'Intellisense. Il semble que ce soit plus commode pour faire ça d'afficher en mode Source qu'en mode Design, si tant est d'ailleurs qu'on puisse faire autrement.)
