Il faut croire que cet apr=E8s-midi j'=E9tais dans de bonnes conditions p=
our=20
effectuer des recherches, j'ignore si c'est moi qui =E9tais en progr=E8s =
ou=20
si ce sont les moteurs de recherche, toujours est-il que la r=E9ponse=20
=E9tait dans la premi=E8re page de r=E9sultats :
J'avais bien d=E9j=E0 vu quelque part que quelqu'un conseillait de d=E9fi=
nir=20
les donn=E9es par code, mais comme la doc disait qu'on pouvait faire sans=
,=20
je continuais =E0 chercher. L=E0, c'est, selon la signature, un responsab=
le=20
du support technique de Microsoft qui confirme qu'il s'agit bien d'un=20
bug, qu'on arrive =E0 contourner avec quelques lignes de code -jusqu'=E0 =
avoir install=E9 la mise =E0 jour ad hoc.
Par ailleurs il convient d'introduire les donn=E9es de l'=E9tat et du=20
sous-=E9tat en composant du formulaire par un gliss=E9 de souris depuis l=
a=20
fen=EAtre Data Sources. Je n'ai pas =E9tabli de lourdes batteries de test=
=20
pour =E9tablir ce qui est indispensable et ce qui ne l'est pas, mais enfi=
n=20
avec =E7a c'est bon.
A part =E7a, du fait que le d=E9faut ne se manifeste pas =E0 tous les cou=
ps en=20
fonction de comment on d=E9finit l'=E9tat et le sous-=E9tat, j'imagine qu=
'en=20
plongeant dans leurs codes avec un =E9diteur XML on devrait r=E9ussir =E0=
en=20
dire plus et dans certains cas =E0 =EAtre capable de les refaire de fa=E7=
on=20
qu'ils fonctionnent sans =E9crire de code. Cela =E9tant, la plateforme=20
donnant largement de quoi s'occuper, je vais peut-=EAtre me contenter=20
d'appliquer ce contournement propos=E9 par Microsoft soi-m=EAme, et r=E9v=
iser=20
des bricoles comme les appels de webservices ou d'autres du genre, en=20
d'autres termes clore le chapitre.
Merci =E0 ceux qui ont pass=E9 du temps l=E0-dessus, notamment J=E9r=E9my=
qui=20
s'est manifest=E9.
Merci pour l'information, je crois que l'on est un certain nombre à qui cela pourra servir le moment venu ;) -- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour gloops,
Merci pour l'information, je crois que l'on est un certain nombre à qui
cela pourra servir le moment venu ;)
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Merci pour l'information, je crois que l'on est un certain nombre à qui cela pourra servir le moment venu ;) -- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Jérémy Jeanson a écrit, le 31/07/2009 15:30 :
Bonjour gloops,
Merci pour l'information, je crois que l'on est un certain nombre à q ui cela pourra servir le moment venu ;)
Ah, dans le fond ça se pourrait bien, ça. :) J'ai aussi de quoi faire sur d'autres sujets, mais je finirai bien par me fendre d'une page web sur la question.
Depuis le code pour initialiser la source de données du formulaire, j'a i aussi découvert autre chose, valable pendant la phase de développemen t cette fois : au niveau de la commande Choose DataSources du smarttag du ReportViewer, il convient de sélectionner d'abord la source de donnée s du sous-état, et puis juste après celle de l'état principal. ça p eut surprendre puisque cette zone n'accepte qu'une valeur, mais lorsqu'on sélectionne une source de données à cet endroit, cela génère automatiquement les objets d'accès, sous le formulaire. C'est d'ailleur s le nom de la BindingSource ainsi créée pour le sous-état qu'il y au ra lieu de reporter dans la procédure SetSubDataSource, en deuxième argument du ReportDataSource ajouté (ce n'est donc pas nécessairement superflu d'en prendre note avant de créer l'autre). Le premier argument , quant à lui, fera référence au DataSet et à la DataTable sélect ionnées en DataSource. Le format, comme on peut s'y attendre, est assez simple : entre guillemets, inscrire le nom du DataSet, suivi d'un caractère de soulignement, puis du nom de la DataTable.
Bien entendu, il faut réaliser ces manÂœuvres le nombre de fois voulu pour éviter d'être désorienté par les listes qui ne se rafraichis sent pas forcément au moment où on s'y attend, par exemple. ça fait que si on fait ce genre de découverte devant le client, ça peut le rendre nerve ux :) Sans compter qu'on a vite fait d'oublier d'ajouter la référence, en h aut du module.
Pour se rappeler le code à insérer dans le module, il s'avère que Microsoft a édité quelques fiches là-dessus, ce qui peut être intéressant le moment venu si on n'a pas besoin d'étudier toute la littérature qui va avec.
Avec les critères ReportViewer SubReport microsoft kb on tombe par exemple sur http://www.netomatix.com/Articles/KBArticle.aspx?a‘9157 qui mentionne aussi l'adresse : HTTP://SUPPORT.MICROSOFT.COM/KB/919157/EN-US
(mouaif, celle-ci est aussi bien ... d'ailleurs selon le moteur de recherche on peut aussi bien tomber directement dessus ; en minuscules .. .)
Jérémy Jeanson a écrit, le 31/07/2009 15:30 :
Bonjour gloops,
Merci pour l'information, je crois que l'on est un certain nombre à q ui
cela pourra servir le moment venu ;)
Ah, dans le fond ça se pourrait bien, ça. :)
J'ai aussi de quoi faire sur d'autres sujets, mais je finirai bien par
me fendre d'une page web sur la question.
Depuis le code pour initialiser la source de données du formulaire, j'a i
aussi découvert autre chose, valable pendant la phase de développemen t
cette fois : au niveau de la commande Choose DataSources du smarttag du
ReportViewer, il convient de sélectionner d'abord la source de donnée s
du sous-état, et puis juste après celle de l'état principal. ça p eut
surprendre puisque cette zone n'accepte qu'une valeur, mais lorsqu'on
sélectionne une source de données à cet endroit, cela génère
automatiquement les objets d'accès, sous le formulaire. C'est d'ailleur s
le nom de la BindingSource ainsi créée pour le sous-état qu'il y au ra
lieu de reporter dans la procédure SetSubDataSource, en deuxième
argument du ReportDataSource ajouté (ce n'est donc pas nécessairement
superflu d'en prendre note avant de créer l'autre). Le premier argument ,
quant à lui, fera référence au DataSet et à la DataTable sélect ionnées
en DataSource. Le format, comme on peut s'y attendre, est assez simple :
entre guillemets, inscrire le nom du DataSet, suivi d'un caractère de
soulignement, puis du nom de la DataTable.
Bien entendu, il faut réaliser ces manÂœuvres le nombre de fois voulu
pour éviter d'être désorienté par les listes qui ne se rafraichis sent
pas forcément au moment où on s'y attend, par exemple. ça fait que si on
fait ce genre de découverte devant le client, ça peut le rendre nerve ux :)
Sans compter qu'on a vite fait d'oublier d'ajouter la référence, en h aut
du module.
Pour se rappeler le code à insérer dans le module, il s'avère que
Microsoft a édité quelques fiches là-dessus, ce qui peut être
intéressant le moment venu si on n'a pas besoin d'étudier toute la
littérature qui va avec.
Avec les critères
ReportViewer SubReport microsoft kb
on tombe par exemple sur
http://www.netomatix.com/Articles/KBArticle.aspx?a=919157
qui mentionne aussi l'adresse :
HTTP://SUPPORT.MICROSOFT.COM/KB/919157/EN-US
(mouaif, celle-ci est aussi bien ... d'ailleurs selon le moteur de
recherche on peut aussi bien tomber directement dessus ; en minuscules .. .)
Merci pour l'information, je crois que l'on est un certain nombre à q ui cela pourra servir le moment venu ;)
Ah, dans le fond ça se pourrait bien, ça. :) J'ai aussi de quoi faire sur d'autres sujets, mais je finirai bien par me fendre d'une page web sur la question.
Depuis le code pour initialiser la source de données du formulaire, j'a i aussi découvert autre chose, valable pendant la phase de développemen t cette fois : au niveau de la commande Choose DataSources du smarttag du ReportViewer, il convient de sélectionner d'abord la source de donnée s du sous-état, et puis juste après celle de l'état principal. ça p eut surprendre puisque cette zone n'accepte qu'une valeur, mais lorsqu'on sélectionne une source de données à cet endroit, cela génère automatiquement les objets d'accès, sous le formulaire. C'est d'ailleur s le nom de la BindingSource ainsi créée pour le sous-état qu'il y au ra lieu de reporter dans la procédure SetSubDataSource, en deuxième argument du ReportDataSource ajouté (ce n'est donc pas nécessairement superflu d'en prendre note avant de créer l'autre). Le premier argument , quant à lui, fera référence au DataSet et à la DataTable sélect ionnées en DataSource. Le format, comme on peut s'y attendre, est assez simple : entre guillemets, inscrire le nom du DataSet, suivi d'un caractère de soulignement, puis du nom de la DataTable.
Bien entendu, il faut réaliser ces manÂœuvres le nombre de fois voulu pour éviter d'être désorienté par les listes qui ne se rafraichis sent pas forcément au moment où on s'y attend, par exemple. ça fait que si on fait ce genre de découverte devant le client, ça peut le rendre nerve ux :) Sans compter qu'on a vite fait d'oublier d'ajouter la référence, en h aut du module.
Pour se rappeler le code à insérer dans le module, il s'avère que Microsoft a édité quelques fiches là-dessus, ce qui peut être intéressant le moment venu si on n'a pas besoin d'étudier toute la littérature qui va avec.
Avec les critères ReportViewer SubReport microsoft kb on tombe par exemple sur http://www.netomatix.com/Articles/KBArticle.aspx?a‘9157 qui mentionne aussi l'adresse : HTTP://SUPPORT.MICROSOFT.COM/KB/919157/EN-US
(mouaif, celle-ci est aussi bien ... d'ailleurs selon le moteur de recherche on peut aussi bien tomber directement dessus ; en minuscules .. .)
Jérémy Jeanson
Bonjour Gloops,
Etant coutumier des soucis du designer de Report, j'avais complettement oublié de te dire que pour ce qui est des sources de données, je l'ai entièrement laissé tombé. A la place j'ouvre le fichier via Visual Studio comme étant un fichier XML, j'ajoute mes DataSet et Tables. Ensuite je ferme mon fichier et je l'ouvre avec le designer pour éditer le report et positionner mes controles et leur binding aux dataset.
Si tu veux un peu d'informations sur le schema xml utilisé par les reports, j'ai fait un petit résumé il y a quelqus temps ici: http://jjeanson.fr/1/Post.aspx?postR327023-5638-0c89-10d0-8f7f8e3e2a59
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Gloops,
Etant coutumier des soucis du designer de Report, j'avais complettement
oublié de te dire que pour ce qui est des sources de données, je l'ai
entièrement laissé tombé. A la place j'ouvre le fichier via Visual
Studio comme étant un fichier XML, j'ajoute mes DataSet et Tables.
Ensuite je ferme mon fichier et je l'ouvre avec le designer pour éditer
le report et positionner mes controles et leur binding aux dataset.
Si tu veux un peu d'informations sur le schema xml utilisé par les
reports, j'ai fait un petit résumé il y a quelqus temps ici:
http://jjeanson.fr/1/Post.aspx?postR327023-5638-0c89-10d0-8f7f8e3e2a59
Etant coutumier des soucis du designer de Report, j'avais complettement oublié de te dire que pour ce qui est des sources de données, je l'ai entièrement laissé tombé. A la place j'ouvre le fichier via Visual Studio comme étant un fichier XML, j'ajoute mes DataSet et Tables. Ensuite je ferme mon fichier et je l'ouvre avec le designer pour éditer le report et positionner mes controles et leur binding aux dataset.
Si tu veux un peu d'informations sur le schema xml utilisé par les reports, j'ai fait un petit résumé il y a quelqus temps ici: http://jjeanson.fr/1/Post.aspx?postR327023-5638-0c89-10d0-8f7f8e3e2a59
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Gloops
Jérémy Jeanson a écrit, le 11/08/2009 09:33 :
Si tu veux un peu d'informations sur le schema xml utilisé par les reports, j'ai fait un petit résumé il y a quelqus temps ici: http://jjeanson.fr/1/Post.aspx?postR327023-5638-0c89-10d0-8f7f8e3e2 a59
Bon, je vais regarder ça, merci, apparemment ça peut être bien pour fignoler quelques trucs.
Pour avoir des largeurs de colonnes différentes pour un entête de gro upe par rapport au détail, ça ne paraissait pas évident puisque tout es t géré dans un tableau. Alors finalement, j'ai fait un sous-état pour l'entête de groupe, et un autre pour le détail, et comme ça on met tout où on veut. De cette manière l'état principal est somme tout simple , un tableau avec regroupement, un sous-état dans la tête de groupe, un au tre sous-état dans le détail, l'entête et le pied de page, point. Je me suis rendu compte aussi que le contrôle sous-état doit être au moins aus si large que l'état défini par le fichier rdlc qu'il reçoit. Sinon, contrairement à ce que j'ai lu quelque part ça ne provoque pas l'erre ur "subreport could not be shown", et même à l'écran on ne voit rien q ui cloche, mais c'est une fois que l'utilisateur demande l'impression qu'il se rend compte que la mise en page obtenue est très surprenante, et il n'est pas garanti du tout qu'il apprécie la surprise.
A propos maintenant je fais ça presque les yeux fermés en Winform, ma is sur web il y aura semble-t-il encore une ou deux séances. La syntaxe pour désigner le dataset est-elle la même ? D'ailleurs l'articulation entre le dataset et son instance de données n'est pas tout-à-fait organisée pareil il me semble.
Pour l'instant, maintenant que j'ai obtenu un état, j'en suis à mieux gérer les données à mettre dedans. On se dit que le DataGridView c' est un truc tout simple, en fait il faut quand même jouer avec une fois ou deux pour que ce soit "fluent". Et même jouer avec chaque type de base à attaquer ...
[HS] Je croyais qu'il y avait un problème de mise à jour (qui rendait nécessaire la procédure définissant les données du sous-état), en fait ce qui traînait depuis six mois (une mise à jour reproposée après avoir été installée x fois) est maintenant réglé, il s'agissait de vi der en mode sans échec le répertoire C:WindowsSoftwareDistribution
Jérémy Jeanson a écrit, le 11/08/2009 09:33 :
Si tu veux un peu d'informations sur le schema xml utilisé par les
reports, j'ai fait un petit résumé il y a quelqus temps ici:
http://jjeanson.fr/1/Post.aspx?post=52327023-5638-0c89-10d0-8f7f8e3e2 a59
Bon, je vais regarder ça, merci, apparemment ça peut être bien pour
fignoler quelques trucs.
Pour avoir des largeurs de colonnes différentes pour un entête de gro upe
par rapport au détail, ça ne paraissait pas évident puisque tout es t
géré dans un tableau. Alors finalement, j'ai fait un sous-état pour
l'entête de groupe, et un autre pour le détail, et comme ça on met tout
où on veut. De cette manière l'état principal est somme tout simple , un
tableau avec regroupement, un sous-état dans la tête de groupe, un au tre
sous-état dans le détail, l'entête et le pied de page, point. Je me suis
rendu compte aussi que le contrôle sous-état doit être au moins aus si
large que l'état défini par le fichier rdlc qu'il reçoit. Sinon,
contrairement à ce que j'ai lu quelque part ça ne provoque pas l'erre ur
"subreport could not be shown", et même à l'écran on ne voit rien q ui
cloche, mais c'est une fois que l'utilisateur demande l'impression qu'il
se rend compte que la mise en page obtenue est très surprenante, et il
n'est pas garanti du tout qu'il apprécie la surprise.
A propos maintenant je fais ça presque les yeux fermés en Winform, ma is
sur web il y aura semble-t-il encore une ou deux séances. La syntaxe
pour désigner le dataset est-elle la même ? D'ailleurs l'articulation
entre le dataset et son instance de données n'est pas tout-à-fait
organisée pareil il me semble.
Pour l'instant, maintenant que j'ai obtenu un état, j'en suis à mieux
gérer les données à mettre dedans. On se dit que le DataGridView c' est
un truc tout simple, en fait il faut quand même jouer avec une fois ou
deux pour que ce soit "fluent". Et même jouer avec chaque type de base à
attaquer ...
[HS] Je croyais qu'il y avait un problème de mise à jour (qui rendait
nécessaire la procédure définissant les données du sous-état), en fait
ce qui traînait depuis six mois (une mise à jour reproposée après avoir
été installée x fois) est maintenant réglé, il s'agissait de vi der en
mode sans échec le répertoire C:WindowsSoftwareDistribution
Si tu veux un peu d'informations sur le schema xml utilisé par les reports, j'ai fait un petit résumé il y a quelqus temps ici: http://jjeanson.fr/1/Post.aspx?postR327023-5638-0c89-10d0-8f7f8e3e2 a59
Bon, je vais regarder ça, merci, apparemment ça peut être bien pour fignoler quelques trucs.
Pour avoir des largeurs de colonnes différentes pour un entête de gro upe par rapport au détail, ça ne paraissait pas évident puisque tout es t géré dans un tableau. Alors finalement, j'ai fait un sous-état pour l'entête de groupe, et un autre pour le détail, et comme ça on met tout où on veut. De cette manière l'état principal est somme tout simple , un tableau avec regroupement, un sous-état dans la tête de groupe, un au tre sous-état dans le détail, l'entête et le pied de page, point. Je me suis rendu compte aussi que le contrôle sous-état doit être au moins aus si large que l'état défini par le fichier rdlc qu'il reçoit. Sinon, contrairement à ce que j'ai lu quelque part ça ne provoque pas l'erre ur "subreport could not be shown", et même à l'écran on ne voit rien q ui cloche, mais c'est une fois que l'utilisateur demande l'impression qu'il se rend compte que la mise en page obtenue est très surprenante, et il n'est pas garanti du tout qu'il apprécie la surprise.
A propos maintenant je fais ça presque les yeux fermés en Winform, ma is sur web il y aura semble-t-il encore une ou deux séances. La syntaxe pour désigner le dataset est-elle la même ? D'ailleurs l'articulation entre le dataset et son instance de données n'est pas tout-à-fait organisée pareil il me semble.
Pour l'instant, maintenant que j'ai obtenu un état, j'en suis à mieux gérer les données à mettre dedans. On se dit que le DataGridView c' est un truc tout simple, en fait il faut quand même jouer avec une fois ou deux pour que ce soit "fluent". Et même jouer avec chaque type de base à attaquer ...
[HS] Je croyais qu'il y avait un problème de mise à jour (qui rendait nécessaire la procédure définissant les données du sous-état), en fait ce qui traînait depuis six mois (une mise à jour reproposée après avoir été installée x fois) est maintenant réglé, il s'agissait de vi der en mode sans échec le répertoire C:WindowsSoftwareDistribution
