Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Export par sous-état

3 réponses
Avatar
Gloops
Bonjour tout le monde,

J'ai r=E9alis=E9 un export Excel au sein d'un =E9tat.

Pour situer un peu, l'=E9tat est ouvert par un formulaire, qui comporte u=
n=20
groupe d'options pour dire si on en veut une impression directe ou une=20
pr=E9visualisation, j'ai ajout=E9 un troisi=E8me mode pour l'export Excel=
,=20
pour lequel je r=E9alise l'impression sur une imprimante en fichier texte=
,=20
que j'invite l'utilisateur =E0 s=E9lectionner lors de l'installation.

Comme je l'ai mentionn=E9 ici, en fonction du degr=E9 de sophistication=20
rencontr=E9 en cours de route et du caract=E8re peu =E9vident du d=E9boga=
ge, si=20
c'=E9tait =E0 refaire je ferais plut=F4t un module qui r=E9alise l'export=
=2E=20
Toutefois, j'ai l'avantage de me r=E9f=E9rer aux contr=F4les de l'=E9tat,=
=20
moyennant quoi je m'attends, au d=E9part, =E0 ce que les valeurs=20
correspondent =E0 ce qui s'imprime (m=EAme si en fait j'ai une petite=20
surprise =E0 ce niveau, mais passons).

Un pied de groupe est r=E9alis=E9 par sous-=E9tat, c'est comme cela que j=
'ai=20
trouv=E9 cet =E9tat. Il m'a paru plus simple de r=E9aliser l'export des=20
valeurs des contr=F4les de ce sous-=E9tat, dans le code du sous-=E9tat pl=
ut=F4t=20
que de l'=E9tat principal.

Peut-=EAtre n'=E9tait-ce pas une bonne id=E9e : les lignes correspondante=
s=20
s'exportent trois fois. En fait, je fais syst=E9matiquement un test de=20
PrintCount =3D 1, mais le sous-=E9tat se formate trois fois avec PrintCou=
nt=20
=E0 1 et FormatCount =E0 1. J'imagine qu'il faudrait que je me r=E9f=E8re=
=E0 une=20
propri=E9t=E9 du pied de groupe dans l'=E9tat principal, mais la premi=E8=
re=20
approche pour tester Parent.FormatCount a =E9t=E9 snob=E9e totalement.

Quelqu'un voit-il une meilleure syntaxe pour ne r=E9aliser qu'une fois un=
e=20
op=E9ration sur un sous-=E9tat pr=E9sent dans un pied de groupe ?

En attendant je retourne =E0 la premi=E8re tentative que j'avais faite de=
=20
faire l'export depuis l'=E9tat principal, mais si je ne me rappelle bien =

je n'avais pas les donn=E9es dedans.

3 réponses

Avatar
Gloops
Gloops a écrit, le 06/02/2012 19:10 :
une imprimante en fichier texte



L'expression exacte serait plutôt une imprimante en mode fichier
(exemple : PrintToPDF)
Avatar
Gloops
Gloops a écrit, le 06/02/2012 19:10 :
Bonjour tout le monde,

J'ai réalisé un export Excel au sein d'un état.

Pour situer un peu, l'état est ouvert par un formulaire, qui comporte un
groupe d'options pour dire si on en veut une impression directe ou une
prévisualisation, j'ai ajouté un troisième mode pour l'export Exc el,
pour lequel je réalise l'impression sur une imprimante en fichier tex te,
que j'invite l'utilisateur à sélectionner lors de l'installation.

Comme je l'ai mentionné ici, en fonction du degré de sophistication
rencontré en cours de route et du caractère peu évident du débo gage, si
c'était à refaire je ferais plutôt un module qui réalise l'expo rt.
Toutefois, j'ai l'avantage de me référer aux contrôles de l'éta t,
moyennant quoi je m'attends, au départ, à ce que les valeurs
correspondent à ce qui s'imprime (même si en fait j'ai une petite
surprise à ce niveau, mais passons).

Un pied de groupe est réalisé par sous-état, c'est comme cela que j'ai
trouvé cet état. Il m'a paru plus simple de réaliser l'export des
valeurs des contrôles de ce sous-état, dans le code du sous-état plutôt
que de l'état principal.

Peut-être n'était-ce pas une bonne idée : les lignes correspondan tes
s'exportent trois fois. En fait, je fais systématiquement un test de
PrintCount = 1, mais le sous-état se formate trois fois avec PrintC ount
à 1 et FormatCount à 1. J'imagine qu'il faudrait que je me réfè re à une
propriété du pied de groupe dans l'état principal, mais la premiè re
approche pour tester Parent.FormatCount a été snobée totalement.

Quelqu'un voit-il une meilleure syntaxe pour ne réaliser qu'une fois une
opération sur un sous-état présent dans un pied de groupe ?

En attendant je retourne à la première tentative que j'avais faite de
faire l'export depuis l'état principal, mais si je ne me rappelle bie n
je n'avais pas les données dedans.





Bon, le développement a été remis.
Pour schématiser, j'ai développé une usine à gaz par dessus une a utre
usine à gaz pré-existante. Comprendre au juste pourquoi il y avait de s
doublons devenait un peu délicat.

Alors ... j'ai ajouté quelques manettes à la deuxième usine à gaz .
J'ai créé des tables pour mémoriser les clefs traitées, de faço n à ne
les exporter qu'une fois.

Ce n'est probablement pas le plus élégant, mais ça marche.

Étant donné que le prochain projet dont j'ai entendu parler est la
migration de cette application sous une autre plateforme, j'ai comme
l'impression qu'à ce stade je ne vais pas consacrer beaucoup d'énergi e à
chercher quelque chose de plus élégant, puisque l'utilisateur a
semble-t-il obtenu ce qu'il demandait.
Avatar
Gloops
Gloops a écrit, le 06/02/2012 19:10 :
Comme je l'ai mentionné ici, en fonction du degré de sophistication
rencontré en cours de route et du caractère peu évident du débo gage, si
c'était à refaire je ferais plutôt un module qui réalise l'expo rt.
Toutefois, j'ai l'avantage de me référer aux contrôles de l'éta t,
moyennant quoi je m'attends, au départ, à ce que les valeurs
correspondent à ce qui s'imprime (même si en fait j'ai une petite
surprise à ce niveau, mais passons).



Quand on m'a parlé, par téléphone, des corrections à effectuer, j e me
suis demandé si j'allais m'orienter vers la réécriture de l'export dans
un module. Finalement, pour juste filtrer les lignes qui sortent et
corriger leur ordre, ça aurait été dommage. Il aurait fallu refaire tous
les calculs, avec des risques d'erreurs.
ça m'a demandé un peu de temps, de tâtonnement (ah oui parce que
l'exécution en pas à pas est exclue dans ce contexte), mais au moins je
savais que les valeurs qui sortaient étaient les bonnes.

Un point qui déroute la première fois qu'on y est confronté : dans la
plupart des cas, en cas d'erreur, une procédure d'erreur bien écrite
permet de voir rapidement de quoi il retourne ; mais il y a des exception s.

Dans le cas d'un appel à un objet non défini (par exemple déclaré dans
un autre module sans clause Public), l'exécution de la procédure
s'interrompt, et on revient à la procédure appelante sans aucun messa ge.
Il faut un peu de temps pour réaliser au juste où se trouve le problè me.
J'ai truffé la procédure de MsgBox pour voir quel est le premier qui ne
s'affiche pas alors qu'il devrait.

Une fois que j'ai vu sur quelle ligne s'interrompt l'exécution, la caus e
est devenue évidente.