(undefined ?) Redimensionnement de tableau dans une récurrence
15 réponses
Gloops
Bonjour tout le monde,
Trou de m=E9moire : je cherche la doc sur le mot-clef undefined, mais je =
n'ai trouv=E9 =E7a que pour JScript, donc mauvaise pioche pour C# peut-=EA=
tre=20
bien. Alors j'ai essay=E9 avec null, mais =E7a n'a pas l'air d'=EAtre bie=
n =E7a.
Je suis en train de traduire en C# un projet que j'ai trouv=E9 en VB pour=
=20
s=E9rialiser un treeview (plagiat ? S=FBrement, un peu :) )
A toutes fins utiles, la source est l=E0 :
http://www.codeproject.com/KB/vb/TreeViewDataAccess/TreeViewDataAccess_de=
mo.zip
Et je suis en train de me cogner =E0 la vitre pour cette instruction :
ReDim Nodes(node.Nodes.Count - 1)
On me dit qu'=E0 la fin de ceci j'ai "Use of possibly unassigned field=20
'Nodes'". J'ai pris soin de v=E9rifier qu'il n'=E9tait pas nul, mais si i=
l=20
n'est pas d=E9fini il semblerait qu'il soit interdit de se demander si il=
=20
est nul ?
Accessoirement, on me dit aussi que Tag et Nodes doivent =EAtre "fully=20
assigned before control leaves the constructor". J'ai l'impression que=20
l'erreur est plus ou moins la m=EAme.
Attention à la manière dont tu écris ton fichier! Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel niveau? Je pose la question car bien souvent les soucis d'encodage proviennent de la stream utilisée pour l'écriture : il faut penser à lui indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la stream par défaut est en ANSI, en fait de n'est pas vrai et il faut lui passer explicitement l'argument d'encoding default pour avoir un ANSI valable. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Gloops,
Attention à la manière dont tu écris ton fichier!
Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel
niveau? Je pose la question car bien souvent les soucis d'encodage
proviennent de la stream utilisée pour l'écriture : il faut penser à lui
indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la
stream par défaut est en ANSI, en fait de n'est pas vrai et il faut lui
passer explicitement l'argument d'encoding default pour avoir un ANSI
valable.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Attention à la manière dont tu écris ton fichier! Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel niveau? Je pose la question car bien souvent les soucis d'encodage proviennent de la stream utilisée pour l'écriture : il faut penser à lui indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la stream par défaut est en ANSI, en fait de n'est pas vrai et il faut lui passer explicitement l'argument d'encoding default pour avoir un ANSI valable. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Jérémy Jeanson a écrit, le 25/05/2009 10:29 :
Bonjour Gloops,
Attention à la manière dont tu écris ton fichier! Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel niveau? Je pose la question car bien souvent les soucis d'encodage proviennent de la stream utilisée pour l'écriture : il faut penser à lui indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la stream par défaut est en ANSI, en fait de n'est pas vrai et il faut l ui passer explicitement l'argument d'encoding default pour avoir un ANSI valable.
Bonjour,
C'est vrai que j'ai un peu laissé de côté cette histoire d'encodage , que j'avais initialement prévu de traiter le lendemain. J'ai toutefois ét é confronté à la même question pour un fichier texte (enregistrement de dates/heures de connexion), on peut définir un encodage pour créer la chaîne, mais si on utilise une instruction qui ne reconnaît qu'un encodage, celui utilisé pour créer la chaîne est ignoré. Il faut donner l'encodage lors de l'ouverture du fichier.
Bon, je vais bien trouver un moment pour revenir là-dessus (d'ailleurs on annonce de la pluie :) ). Fixer le jeu de caractères ne m'inquiète pas trop, ce qui m'intriguai t le plus était que WriteEndDocument ne me mette pas </xml>. Comme IE ne s'en formalise pas peut-être peut-on passer outre, bien que se baser su r IE pour juger le respect d'une norme, hum, comment dire, peut-être n'est-ce pas une bonne idée.
C'est vrai que j'ai un peu levé le pied sur cette histoire de sérialisation quand j'ai réalisé que ça ne me ferait pas progress er sur les fenêtres du numéroteur téléphonique ...
Mouaip, à part ça, pour sortir du sujet du fil (mais aussi bien les interlocuteurs sont les mêmes), le sous-état laisse tout le monde sec aussi sur microsoft.public.dotnet.general
On dirait que je ne fournis pas assez d'éléments, mais pour le moment je me demande bien où en chercher. J'avais l'impression que partir d'un projet existant en ligne devait permettre d'avoir un socle d'éléments communs. Ou alors ce sont mes données qui sont en cause, enfin a priori j'ai du mal à me représenter ça. Dataset non instancié, apparemme nt, ça n'a rien évoqué à personne.
Jérémy Jeanson a écrit, le 25/05/2009 10:29 :
Bonjour Gloops,
Attention à la manière dont tu écris ton fichier!
Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel
niveau? Je pose la question car bien souvent les soucis d'encodage
proviennent de la stream utilisée pour l'écriture : il faut penser à lui
indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la
stream par défaut est en ANSI, en fait de n'est pas vrai et il faut l ui
passer explicitement l'argument d'encoding default pour avoir un ANSI
valable.
Bonjour,
C'est vrai que j'ai un peu laissé de côté cette histoire d'encodage , que
j'avais initialement prévu de traiter le lendemain. J'ai toutefois ét é
confronté à la même question pour un fichier texte (enregistrement de
dates/heures de connexion), on peut définir un encodage pour créer la
chaîne, mais si on utilise une instruction qui ne reconnaît qu'un
encodage, celui utilisé pour créer la chaîne est ignoré. Il faut donner
l'encodage lors de l'ouverture du fichier.
Bon, je vais bien trouver un moment pour revenir là-dessus (d'ailleurs
on annonce de la pluie :) ).
Fixer le jeu de caractères ne m'inquiète pas trop, ce qui m'intriguai t
le plus était que WriteEndDocument ne me mette pas </xml>. Comme IE ne
s'en formalise pas peut-être peut-on passer outre, bien que se baser su r
IE pour juger le respect d'une norme, hum, comment dire, peut-être
n'est-ce pas une bonne idée.
C'est vrai que j'ai un peu levé le pied sur cette histoire de
sérialisation quand j'ai réalisé que ça ne me ferait pas progress er sur
les fenêtres du numéroteur téléphonique ...
Mouaip, à part ça, pour sortir du sujet du fil (mais aussi bien les
interlocuteurs sont les mêmes), le sous-état laisse tout le monde sec
aussi sur microsoft.public.dotnet.general
On dirait que je ne fournis pas assez d'éléments, mais pour le moment je
me demande bien où en chercher. J'avais l'impression que partir d'un
projet existant en ligne devait permettre d'avoir un socle d'éléments
communs. Ou alors ce sont mes données qui sont en cause, enfin a priori
j'ai du mal à me représenter ça. Dataset non instancié, apparemme nt, ça
n'a rien évoqué à personne.
Attention à la manière dont tu écris ton fichier! Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel niveau? Je pose la question car bien souvent les soucis d'encodage proviennent de la stream utilisée pour l'écriture : il faut penser à lui indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la stream par défaut est en ANSI, en fait de n'est pas vrai et il faut l ui passer explicitement l'argument d'encoding default pour avoir un ANSI valable.
Bonjour,
C'est vrai que j'ai un peu laissé de côté cette histoire d'encodage , que j'avais initialement prévu de traiter le lendemain. J'ai toutefois ét é confronté à la même question pour un fichier texte (enregistrement de dates/heures de connexion), on peut définir un encodage pour créer la chaîne, mais si on utilise une instruction qui ne reconnaît qu'un encodage, celui utilisé pour créer la chaîne est ignoré. Il faut donner l'encodage lors de l'ouverture du fichier.
Bon, je vais bien trouver un moment pour revenir là-dessus (d'ailleurs on annonce de la pluie :) ). Fixer le jeu de caractères ne m'inquiète pas trop, ce qui m'intriguai t le plus était que WriteEndDocument ne me mette pas </xml>. Comme IE ne s'en formalise pas peut-être peut-on passer outre, bien que se baser su r IE pour juger le respect d'une norme, hum, comment dire, peut-être n'est-ce pas une bonne idée.
C'est vrai que j'ai un peu levé le pied sur cette histoire de sérialisation quand j'ai réalisé que ça ne me ferait pas progress er sur les fenêtres du numéroteur téléphonique ...
Mouaip, à part ça, pour sortir du sujet du fil (mais aussi bien les interlocuteurs sont les mêmes), le sous-état laisse tout le monde sec aussi sur microsoft.public.dotnet.general
On dirait que je ne fournis pas assez d'éléments, mais pour le moment je me demande bien où en chercher. J'avais l'impression que partir d'un projet existant en ligne devait permettre d'avoir un socle d'éléments communs. Ou alors ce sont mes données qui sont en cause, enfin a priori j'ai du mal à me représenter ça. Dataset non instancié, apparemme nt, ça n'a rien évoqué à personne.
Jérémy Jeanson
Bonjour Gloops,
Je viens de prendre deux secondes pour regarder l'un de mes projet qui utilise la sérialisation dont je te parlais et je constat que j'ai bien en début de fichier la balise XML... par contr je me demande si tu ne te poserais pas une question qui n'en est pas une.
Je m'expliques: tu ne confondrait pas <xml> qui doit effectivement avoir une fin genre si il a un contenu </xml> ou alors être sur une seule ligne <xml/> avec <?xml version="1.0" ?> qui n'a pas besoin de "/" en fin ?
PS: je crois que je vais regarder un peu ton histoire de report (j'en ai déjà pas mal fait sans rencontré de soucis, mais je suis dans un cadre où je fourni ma donnée en amont du report et non pas sous forme de requêtes effectuées par le report... je vais regarder les différences et repasser dans le post que tu as ouvert). En plus cela tombe bien je dois refaire du report pour mon client. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Gloops,
Je viens de prendre deux secondes pour regarder l'un de mes projet qui
utilise la sérialisation dont je te parlais et je constat que j'ai bien
en début de fichier la balise XML... par contr je me demande si tu ne te
poserais pas une question qui n'en est pas une.
Je m'expliques: tu ne confondrait pas <xml> qui doit effectivement
avoir une fin genre si il a un contenu </xml> ou alors être sur une
seule ligne <xml/> avec <?xml version="1.0" ?> qui n'a pas besoin de "/"
en fin ?
PS: je crois que je vais regarder un peu ton histoire de report (j'en ai
déjà pas mal fait sans rencontré de soucis, mais je suis dans un cadre
où je fourni ma donnée en amont du report et non pas sous forme de
requêtes effectuées par le report... je vais regarder les différences et
repasser dans le post que tu as ouvert). En plus cela tombe bien je dois
refaire du report pour mon client.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Je viens de prendre deux secondes pour regarder l'un de mes projet qui utilise la sérialisation dont je te parlais et je constat que j'ai bien en début de fichier la balise XML... par contr je me demande si tu ne te poserais pas une question qui n'en est pas une.
Je m'expliques: tu ne confondrait pas <xml> qui doit effectivement avoir une fin genre si il a un contenu </xml> ou alors être sur une seule ligne <xml/> avec <?xml version="1.0" ?> qui n'a pas besoin de "/" en fin ?
PS: je crois que je vais regarder un peu ton histoire de report (j'en ai déjà pas mal fait sans rencontré de soucis, mais je suis dans un cadre où je fourni ma donnée en amont du report et non pas sous forme de requêtes effectuées par le report... je vais regarder les différences et repasser dans le post que tu as ouvert). En plus cela tombe bien je dois refaire du report pour mon client. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Jérémy Jeanson a écrit, le 26/05/2009 08:06 :
Bonjour Gloops,
Je viens de prendre deux secondes pour regarder l'un de mes projet qui utilise la sérialisation dont je te parlais et je constat que j'ai bi en en début de fichier la balise XML... par contr je me demande si tu ne te poserais pas une question qui n'en est pas une.
Je m'expliques: tu ne confondrait pas <xml> qui doit effectivement avoir une fin genre si il a un contenu </xml> ou alors être sur une seule ligne <xml/> avec <?xml version="1.0" ?> qui n'a pas besoin de "/" en fin ?
Ah, effectivement ... Et c'est l'un ou l'autre, alors ?
PS: je crois que je vais regarder un peu ton histoire de report (j'en a i déjà pas mal fait sans rencontré de soucis, mais je suis dans un cadre où je fourni ma donnée en amont du report et non pas sous forme de requêtes effectuées par le report... je vais regarder les différe nces et repasser dans le post que tu as ouvert). En plus cela tombe bien je doi s refaire du report pour mon client.
Merci ... Je dois avouer qu'être incapable d'afficher mes données, ç a la fiche un peu mal.
Jérémy Jeanson a écrit, le 26/05/2009 08:06 :
Bonjour Gloops,
Je viens de prendre deux secondes pour regarder l'un de mes projet qui
utilise la sérialisation dont je te parlais et je constat que j'ai bi en
en début de fichier la balise XML... par contr je me demande si tu ne te
poserais pas une question qui n'en est pas une.
Je m'expliques: tu ne confondrait pas <xml> qui doit effectivement
avoir une fin genre si il a un contenu </xml> ou alors être sur une
seule ligne <xml/> avec <?xml version="1.0" ?> qui n'a pas besoin de "/"
en fin ?
Ah, effectivement ... Et c'est l'un ou l'autre, alors ?
PS: je crois que je vais regarder un peu ton histoire de report (j'en a i
déjà pas mal fait sans rencontré de soucis, mais je suis dans un cadre
où je fourni ma donnée en amont du report et non pas sous forme de
requêtes effectuées par le report... je vais regarder les différe nces et
repasser dans le post que tu as ouvert). En plus cela tombe bien je doi s
refaire du report pour mon client.
Merci ... Je dois avouer qu'être incapable d'afficher mes données, ç a la
fiche un peu mal.
Je viens de prendre deux secondes pour regarder l'un de mes projet qui utilise la sérialisation dont je te parlais et je constat que j'ai bi en en début de fichier la balise XML... par contr je me demande si tu ne te poserais pas une question qui n'en est pas une.
Je m'expliques: tu ne confondrait pas <xml> qui doit effectivement avoir une fin genre si il a un contenu </xml> ou alors être sur une seule ligne <xml/> avec <?xml version="1.0" ?> qui n'a pas besoin de "/" en fin ?
Ah, effectivement ... Et c'est l'un ou l'autre, alors ?
PS: je crois que je vais regarder un peu ton histoire de report (j'en a i déjà pas mal fait sans rencontré de soucis, mais je suis dans un cadre où je fourni ma donnée en amont du report et non pas sous forme de requêtes effectuées par le report... je vais regarder les différe nces et repasser dans le post que tu as ouvert). En plus cela tombe bien je doi s refaire du report pour mon client.
Merci ... Je dois avouer qu'être incapable d'afficher mes données, ç a la fiche un peu mal.
Gloops
Bon alors effectivement, non seulement on peut préciser l'encodage à l'ouverture par
Encoding enc = Encoding.GetEncoding("ISO-8859-15"); // avec des syntaxes plus légères pour certains encodages writer = new XmlTextWriter(strCheminFichier, enc);
Mais en plus on peut dire au fichier de se présenter proprement (pour u n humain) par writer.Formatting = Formatting.Indented; _____________________________________________ Jérémy Jeanson a écrit, le 25/05/2009 10:29 :
Bonjour Gloops,
Attention à la manière dont tu écris ton fichier! Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel niveau? Je pose la question car bien souvent les soucis d'encodage proviennent de la stream utilisée pour l'écriture : il faut penser à lui indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la stream par défaut est en ANSI, en fait de n'est pas vrai et il faut l ui passer explicitement l'argument d'encoding default pour avoir un ANSI valable.
Bon alors effectivement, non seulement on peut préciser l'encodage à
l'ouverture par
Encoding enc = Encoding.GetEncoding("ISO-8859-15");
// avec des syntaxes plus légères pour certains encodages
writer = new XmlTextWriter(strCheminFichier, enc);
Mais en plus on peut dire au fichier de se présenter proprement (pour u n
humain) par
writer.Formatting = Formatting.Indented;
_____________________________________________
Jérémy Jeanson a écrit, le 25/05/2009 10:29 :
Bonjour Gloops,
Attention à la manière dont tu écris ton fichier!
Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel
niveau? Je pose la question car bien souvent les soucis d'encodage
proviennent de la stream utilisée pour l'écriture : il faut penser à lui
indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la
stream par défaut est en ANSI, en fait de n'est pas vrai et il faut l ui
passer explicitement l'argument d'encoding default pour avoir un ANSI
valable.
Bon alors effectivement, non seulement on peut préciser l'encodage à l'ouverture par
Encoding enc = Encoding.GetEncoding("ISO-8859-15"); // avec des syntaxes plus légères pour certains encodages writer = new XmlTextWriter(strCheminFichier, enc);
Mais en plus on peut dire au fichier de se présenter proprement (pour u n humain) par writer.Formatting = Formatting.Indented; _____________________________________________ Jérémy Jeanson a écrit, le 25/05/2009 10:29 :
Bonjour Gloops,
Attention à la manière dont tu écris ton fichier! Dans ton cas tu as choisi de modifier par la table ISO-8859-15 à quel niveau? Je pose la question car bien souvent les soucis d'encodage proviennent de la stream utilisée pour l'écriture : il faut penser à lui indiquer un encodage et ne surtout pas le laisser vide.
Oui je sais c'est étrange mais même si par défaut la MSDN dit que la stream par défaut est en ANSI, en fait de n'est pas vrai et il faut l ui passer explicitement l'argument d'encoding default pour avoir un ANSI valable.
