La bordure s'est avérée nécessaire pour que l'alignement se fasse à
droite, mais ça c'est plutôt dans le sujet HTML.
Comme format d'affichage, j'ai essayé {0:f2}, {0:n2}, {0,2}, mais la
seule façon que j'arrive à faire consentir ASP à m'afficher la donnée
autrement qu'avec quatre chiffres derrière la virgule, c'est de lui
mettre un format délirant, sans les accolades par exemple, ou avec une
lettre non reconnue, façon de m'assurer que je ne suis pas en train de
formater une autre colonne que celle que je croyais.
J'ai l'impression que j'ai dû oublier quelque chose quelque part, qui
fait qu'on prend en compte ou pas le format ...
A propos, il m'a pourtant semblé lire dans l'aide de la propriété
DataFormatString qu'on pouvait y mettre des formats personnalisés du
style ###,###,###.## mais si je fais ça le format s'affiche tel quel, à
la place de la donnée et non en la formatant.
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
Jérome Noirfalise
Bonjour,
En fait, le problème est que pour prévenir des attaques cross site scripting, la valeur du champs est encodée en HTML (HtmlEncode). Le soucis est que l'encodage en HTML se fait avant le DataFormaString ce qui fait que ce dernier n'a aucun effet.
Par contre, en déclarant l'attribut HtmlEncode à false dans ton BoundField, le formatage se fera correctement.
En reprenant ton bout de code: <asp:BoundField DataField="StandardCost" HeaderText="Stand. Cost" DataFormatString="{0:n2}" ConvertEmptyStringToNull="False" HtmlEncode="False"> <ItemStyle HorizontalAlign="Right" BorderColor="Black" BorderStyle="Dotted" /> </asp:BoundField>
La bordure s'est avérée nécessaire pour que l'alignement se fasse à droite, mais ça c'est plutôt dans le sujet HTML.
Comme format d'affichage, j'ai essayé {0:f2}, {0:n2}, {0,2}, mais la seule façon que j'arrive à faire consentir ASP à m'afficher la donnée autrement qu'avec quatre chiffres derrière la virgule, c'est de lui mettre un format délirant, sans les accolades par exemple, ou avec une lettre non reconnue, façon de m'assurer que je ne suis pas en train de formater une autre colonne que celle que je croyais.
J'ai l'impression que j'ai dû oublier quelque chose quelque part, qui fait qu'on prend en compte ou pas le format ...
A propos, il m'a pourtant semblé lire dans l'aide de la propriété DataFormatString qu'on pouvait y mettre des formats personnalisés du style ###,###,###.## mais si je fais ça le format s'affiche tel quel, à la place de la donnée et non en la formatant.
Autre chose que j'ai laissé passer ?
Bonjour,
En fait, le problème est que pour prévenir des attaques cross site
scripting, la valeur du champs est encodée en HTML (HtmlEncode). Le soucis
est que l'encodage en HTML se fait avant le DataFormaString ce qui fait que
ce dernier n'a aucun effet.
Par contre, en déclarant l'attribut HtmlEncode à false dans ton BoundField,
le formatage se fera correctement.
En reprenant ton bout de code:
<asp:BoundField DataField="StandardCost"
HeaderText="Stand. Cost"
DataFormatString="{0:n2}"
ConvertEmptyStringToNull="False"
HtmlEncode="False">
<ItemStyle HorizontalAlign="Right"
BorderColor="Black" BorderStyle="Dotted" />
</asp:BoundField>
La bordure s'est avérée nécessaire pour que l'alignement se fasse à
droite, mais ça c'est plutôt dans le sujet HTML.
Comme format d'affichage, j'ai essayé {0:f2}, {0:n2}, {0,2}, mais la
seule façon que j'arrive à faire consentir ASP à m'afficher la donnée
autrement qu'avec quatre chiffres derrière la virgule, c'est de lui
mettre un format délirant, sans les accolades par exemple, ou avec une
lettre non reconnue, façon de m'assurer que je ne suis pas en train de
formater une autre colonne que celle que je croyais.
J'ai l'impression que j'ai dû oublier quelque chose quelque part, qui
fait qu'on prend en compte ou pas le format ...
A propos, il m'a pourtant semblé lire dans l'aide de la propriété
DataFormatString qu'on pouvait y mettre des formats personnalisés du
style ###,###,###.## mais si je fais ça le format s'affiche tel quel, à
la place de la donnée et non en la formatant.
En fait, le problème est que pour prévenir des attaques cross site scripting, la valeur du champs est encodée en HTML (HtmlEncode). Le soucis est que l'encodage en HTML se fait avant le DataFormaString ce qui fait que ce dernier n'a aucun effet.
Par contre, en déclarant l'attribut HtmlEncode à false dans ton BoundField, le formatage se fera correctement.
En reprenant ton bout de code: <asp:BoundField DataField="StandardCost" HeaderText="Stand. Cost" DataFormatString="{0:n2}" ConvertEmptyStringToNull="False" HtmlEncode="False"> <ItemStyle HorizontalAlign="Right" BorderColor="Black" BorderStyle="Dotted" /> </asp:BoundField>
La bordure s'est avérée nécessaire pour que l'alignement se fasse à droite, mais ça c'est plutôt dans le sujet HTML.
Comme format d'affichage, j'ai essayé {0:f2}, {0:n2}, {0,2}, mais la seule façon que j'arrive à faire consentir ASP à m'afficher la donnée autrement qu'avec quatre chiffres derrière la virgule, c'est de lui mettre un format délirant, sans les accolades par exemple, ou avec une lettre non reconnue, façon de m'assurer que je ne suis pas en train de formater une autre colonne que celle que je croyais.
J'ai l'impression que j'ai dû oublier quelque chose quelque part, qui fait qu'on prend en compte ou pas le format ...
A propos, il m'a pourtant semblé lire dans l'aide de la propriété DataFormatString qu'on pouvait y mettre des formats personnalisés du style ###,###,###.## mais si je fais ça le format s'affiche tel quel, à la place de la donnée et non en la formatant.
Autre chose que j'ai laissé passer ?
Gloops
Jérome Noirfalise a écrit, le 03/03/2007 14:30 :
Bonjour,
En fait, le problème est que pour prévenir des attaques cross site scripting, la valeur du champs est encodée en HTML (HtmlEncode). Le soucis est que l'encodage en HTML se fait avant le DataFormaString ce qui fait que ce dernier n'a aucun effet.
Par contre, en déclarant l'attribut HtmlEncode à false dans ton BoundField, le formatage se fera correctement.
Ah, effectivement ... Merci.
Dans les options, je n'ai pas vu une case "Attrappe-couillon" qu'on pourrait décocher ? :)
Alors tu laisses entendre que ça pose un problème de sécurité d'enlever le HtmlEncode ?
Si en tant que débutant on attend d'être opérationnel avant de se pencher décemment sur ce problème, est-ce qu'on mérite la pendaison ? Mais au fait peut-être que je surestime la difficulté, le HtmlEncode, y a-t-on accès ? Il s'agit de l'affichage d'une table avec un Gridview.
A propos, il m'a pourtant semblé lire dans l'aide de la propriété DataFormatString qu'on pouvait y mettre des formats personnalisés du style ###,###,###.## mais si je fais ça le format s'affiche tel quel, à la place de la donnée et non en la formatant.
Autre chose que j'ai laissé passer ?
Même réponse : une fois le HtmlEncode à False, on peut mettre comme DataFormatString "{0:### ###.##}", mais il faut avouer que "{0:n2}" est plus sobre, et à ce que j'ai pu voir ça donne le même résultat (je suppose même qu'avec des valeurs plus importantes ça doit marcher mieux avec {0:n2}).
Jérome Noirfalise a écrit, le 03/03/2007 14:30 :
Bonjour,
En fait, le problème est que pour prévenir des attaques cross site
scripting, la valeur du champs est encodée en HTML (HtmlEncode). Le soucis
est que l'encodage en HTML se fait avant le DataFormaString ce qui fait que
ce dernier n'a aucun effet.
Par contre, en déclarant l'attribut HtmlEncode à false dans ton BoundField,
le formatage se fera correctement.
Ah, effectivement ... Merci.
Dans les options, je n'ai pas vu une case "Attrappe-couillon" qu'on
pourrait décocher ? :)
Alors tu laisses entendre que ça pose un problème de sécurité d'enlever
le HtmlEncode ?
Si en tant que débutant on attend d'être opérationnel avant de se
pencher décemment sur ce problème, est-ce qu'on mérite la pendaison ?
Mais au fait peut-être que je surestime la difficulté, le HtmlEncode, y
a-t-on accès ? Il s'agit de l'affichage d'une table avec un Gridview.
A propos, il m'a pourtant semblé lire dans l'aide de la propriété
DataFormatString qu'on pouvait y mettre des formats personnalisés du
style ###,###,###.## mais si je fais ça le format s'affiche tel quel, à
la place de la donnée et non en la formatant.
Autre chose que j'ai laissé passer ?
Même réponse : une fois le HtmlEncode à False, on peut mettre comme
DataFormatString "{0:### ###.##}", mais il faut avouer que "{0:n2}" est
plus sobre, et à ce que j'ai pu voir ça donne le même résultat (je
suppose même qu'avec des valeurs plus importantes ça doit marcher mieux
avec {0:n2}).
En fait, le problème est que pour prévenir des attaques cross site scripting, la valeur du champs est encodée en HTML (HtmlEncode). Le soucis est que l'encodage en HTML se fait avant le DataFormaString ce qui fait que ce dernier n'a aucun effet.
Par contre, en déclarant l'attribut HtmlEncode à false dans ton BoundField, le formatage se fera correctement.
Ah, effectivement ... Merci.
Dans les options, je n'ai pas vu une case "Attrappe-couillon" qu'on pourrait décocher ? :)
Alors tu laisses entendre que ça pose un problème de sécurité d'enlever le HtmlEncode ?
Si en tant que débutant on attend d'être opérationnel avant de se pencher décemment sur ce problème, est-ce qu'on mérite la pendaison ? Mais au fait peut-être que je surestime la difficulté, le HtmlEncode, y a-t-on accès ? Il s'agit de l'affichage d'une table avec un Gridview.
A propos, il m'a pourtant semblé lire dans l'aide de la propriété DataFormatString qu'on pouvait y mettre des formats personnalisés du style ###,###,###.## mais si je fais ça le format s'affiche tel quel, à la place de la donnée et non en la formatant.
Autre chose que j'ai laissé passer ?
Même réponse : une fois le HtmlEncode à False, on peut mettre comme DataFormatString "{0:### ###.##}", mais il faut avouer que "{0:n2}" est plus sobre, et à ce que j'ai pu voir ça donne le même résultat (je suppose même qu'avec des valeurs plus importantes ça doit marcher mieux avec {0:n2}).
