Export par sous-état

Le
Gloops
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 u=
n
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 Excel=
,
pour lequel je réalise l'impression sur une imprimante en fichier texte=
,
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éboga=
ge, si
c'était à refaire je ferais plutôt un module qui réalise l'export=
.
Toutefois, j'ai l'avantage de me référer aux contrôles de l'état,=

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 pl=
utôt
que de l'état principal.

Peut-être n'était-ce pas une bonne idée : les lignes correspondante=
s
s'exportent trois fois. En fait, je fais systématiquement un test de
PrintCount = 1, mais le sous-état se formate trois fois avec PrintCou=
nt
à 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 un=
e
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 bien =

je n'avais pas les données dedans.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Gloops
Le #24224901
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)
Gloops
Le #24237031
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.
Gloops
Le #24237021
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.
Publicité
Poster une réponse
Anonyme