Le mecanisme d'indirection permet de construire le nom=20
d'un champ, d'une rubrique de fichier ou le nom d'une=20
variable a partir d'une expression de type chaine.
Ce qui permet de creer des traitements generiques=20
independants des noms de champs, des variables etc... en=20
stockant le nom de la 'cible' a traiter dans une variable=20
interm=E9diare ou dans le champ d'une table.
Access 2000 ne dispose pas d'operateur d'indirection, ni=20
de pointeur (sur l'adresse d'une variable).
Sur base des documentations consultees, il semble=20
qu'Access 2003 n'apporte rien de nouveau a ce niveau.
La fonction Eval est d'une aide toute limitee dans ce cas.
Un utilisateur Access 2003 peut-il me confirmer ce statu=20
quo ?
L'un d'entre vous a-t-il une solution ou une id=E9e ?
Ce qui simplifierait grandement mon code ET son encodage=20
(une vingtaine de calculs statistiques standardises sur un=20
nombre variable de parametres - 150 =E0 1.200 - sur 6=20
annees).=20
Le nombre d'annees ne pose pas de probleme (parametrage=20
des fonctions), mais pour des raisons de compacite et de=20
vitesse de transmission, le format des donnees est=20
variable en ce sens que les parametres non releves ne sont=20
pas transmis et que chaque parametre est donc nomme dans=20
le fichier de donnees.
Le nombre d'items : +/- 350.000 par transmission ne permet=20
pas d'envisager une restructuration manuelle (de toute=20
facon source d'erreurs) et je ne suis pas ma=EEtre du format=20
de ces donnees, dont l'ensemble doit etre retraite chaque=20
fois parce qu'il y a parfois des revisions de donnees=20
anterieures.
L'indirection me permettrait donc de designer la variable=20
a traiter, son champ de stockage et de choisir le=20
traitement a appliquer, ceci de maniere dynamique et en=20
quelques lignes de code.
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
Daniel Carollo
Bonjour Michel!
Le probleme que vous evoquez n'est pas simple, mais en general, on parvient a obtenir une sorte d'indirection en nommant les elements dans la collection que l'on veut atteindre. Par exemple, au lieu de rst!MonChamp, on peut utiliser rst.fields("MonChamp"), ce qui ouvre la porte a Dim strChamp as string strChamp = "MonChamp" rst.fields(strChamp) = blah-blah-blah...
Voyez la documentation d'Access, et celle d'ADO (et eventuellement DAO), elles montrent les collections qui sont disponibles pour acceder aux elements d'Access.
J'espere que ca vous est de quelque utilite...
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
"Michel GESNOT" wrote in message news:bc7701c43806$8faebfd0$ Bonjour,
Le mecanisme d'indirection permet de construire le nom d'un champ, d'une rubrique de fichier ou le nom d'une variable a partir d'une expression de type chaine.
Ce qui permet de creer des traitements generiques independants des noms de champs, des variables etc... en stockant le nom de la 'cible' a traiter dans une variable intermédiare ou dans le champ d'une table.
Access 2000 ne dispose pas d'operateur d'indirection, ni de pointeur (sur l'adresse d'une variable). Sur base des documentations consultees, il semble qu'Access 2003 n'apporte rien de nouveau a ce niveau.
La fonction Eval est d'une aide toute limitee dans ce cas.
Un utilisateur Access 2003 peut-il me confirmer ce statu quo ?
L'un d'entre vous a-t-il une solution ou une idée ? Ce qui simplifierait grandement mon code ET son encodage (une vingtaine de calculs statistiques standardises sur un nombre variable de parametres - 150 à 1.200 - sur 6 annees).
Le nombre d'annees ne pose pas de probleme (parametrage des fonctions), mais pour des raisons de compacite et de vitesse de transmission, le format des donnees est variable en ce sens que les parametres non releves ne sont pas transmis et que chaque parametre est donc nomme dans le fichier de donnees.
Le nombre d'items : +/- 350.000 par transmission ne permet pas d'envisager une restructuration manuelle (de toute facon source d'erreurs) et je ne suis pas maître du format de ces donnees, dont l'ensemble doit etre retraite chaque fois parce qu'il y a parfois des revisions de donnees anterieures.
L'indirection me permettrait donc de designer la variable a traiter, son champ de stockage et de choisir le traitement a appliquer, ceci de maniere dynamique et en quelques lignes de code.
Merci pour vos réponses et vos suggestions.
M. Gesnot
Bonjour Michel!
Le probleme que vous evoquez n'est pas simple, mais en general, on parvient
a obtenir une sorte d'indirection en nommant les elements dans la collection
que l'on veut atteindre. Par exemple, au lieu de rst!MonChamp, on peut
utiliser rst.fields("MonChamp"), ce qui ouvre la porte a
Dim strChamp as string
strChamp = "MonChamp"
rst.fields(strChamp) = blah-blah-blah...
Voyez la documentation d'Access, et celle d'ADO (et eventuellement DAO),
elles montrent les collections qui sont disponibles pour acceder aux
elements d'Access.
J'espere que ca vous est de quelque utilite...
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Michel GESNOT" <anonymous@discussions.microsoft.com> wrote in message
news:bc7701c43806$8faebfd0$a601280a@phx.gbl...
Bonjour,
Le mecanisme d'indirection permet de construire le nom
d'un champ, d'une rubrique de fichier ou le nom d'une
variable a partir d'une expression de type chaine.
Ce qui permet de creer des traitements generiques
independants des noms de champs, des variables etc... en
stockant le nom de la 'cible' a traiter dans une variable
intermédiare ou dans le champ d'une table.
Access 2000 ne dispose pas d'operateur d'indirection, ni
de pointeur (sur l'adresse d'une variable).
Sur base des documentations consultees, il semble
qu'Access 2003 n'apporte rien de nouveau a ce niveau.
La fonction Eval est d'une aide toute limitee dans ce cas.
Un utilisateur Access 2003 peut-il me confirmer ce statu
quo ?
L'un d'entre vous a-t-il une solution ou une idée ?
Ce qui simplifierait grandement mon code ET son encodage
(une vingtaine de calculs statistiques standardises sur un
nombre variable de parametres - 150 à 1.200 - sur 6
annees).
Le nombre d'annees ne pose pas de probleme (parametrage
des fonctions), mais pour des raisons de compacite et de
vitesse de transmission, le format des donnees est
variable en ce sens que les parametres non releves ne sont
pas transmis et que chaque parametre est donc nomme dans
le fichier de donnees.
Le nombre d'items : +/- 350.000 par transmission ne permet
pas d'envisager une restructuration manuelle (de toute
facon source d'erreurs) et je ne suis pas maître du format
de ces donnees, dont l'ensemble doit etre retraite chaque
fois parce qu'il y a parfois des revisions de donnees
anterieures.
L'indirection me permettrait donc de designer la variable
a traiter, son champ de stockage et de choisir le
traitement a appliquer, ceci de maniere dynamique et en
quelques lignes de code.
Le probleme que vous evoquez n'est pas simple, mais en general, on parvient a obtenir une sorte d'indirection en nommant les elements dans la collection que l'on veut atteindre. Par exemple, au lieu de rst!MonChamp, on peut utiliser rst.fields("MonChamp"), ce qui ouvre la porte a Dim strChamp as string strChamp = "MonChamp" rst.fields(strChamp) = blah-blah-blah...
Voyez la documentation d'Access, et celle d'ADO (et eventuellement DAO), elles montrent les collections qui sont disponibles pour acceder aux elements d'Access.
J'espere que ca vous est de quelque utilite...
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
"Michel GESNOT" wrote in message news:bc7701c43806$8faebfd0$ Bonjour,
Le mecanisme d'indirection permet de construire le nom d'un champ, d'une rubrique de fichier ou le nom d'une variable a partir d'une expression de type chaine.
Ce qui permet de creer des traitements generiques independants des noms de champs, des variables etc... en stockant le nom de la 'cible' a traiter dans une variable intermédiare ou dans le champ d'une table.
Access 2000 ne dispose pas d'operateur d'indirection, ni de pointeur (sur l'adresse d'une variable). Sur base des documentations consultees, il semble qu'Access 2003 n'apporte rien de nouveau a ce niveau.
La fonction Eval est d'une aide toute limitee dans ce cas.
Un utilisateur Access 2003 peut-il me confirmer ce statu quo ?
L'un d'entre vous a-t-il une solution ou une idée ? Ce qui simplifierait grandement mon code ET son encodage (une vingtaine de calculs statistiques standardises sur un nombre variable de parametres - 150 à 1.200 - sur 6 annees).
Le nombre d'annees ne pose pas de probleme (parametrage des fonctions), mais pour des raisons de compacite et de vitesse de transmission, le format des donnees est variable en ce sens que les parametres non releves ne sont pas transmis et que chaque parametre est donc nomme dans le fichier de donnees.
Le nombre d'items : +/- 350.000 par transmission ne permet pas d'envisager une restructuration manuelle (de toute facon source d'erreurs) et je ne suis pas maître du format de ces donnees, dont l'ensemble doit etre retraite chaque fois parce qu'il y a parfois des revisions de donnees anterieures.
L'indirection me permettrait donc de designer la variable a traiter, son champ de stockage et de choisir le traitement a appliquer, ceci de maniere dynamique et en quelques lignes de code.
Merci pour vos réponses et vos suggestions.
M. Gesnot
Michel Gesnot
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas encore explore.
Pour info, puisqu'il en est de temps en temps question, Windev dispose d'operateurs d'indirection. Et en sus, les capacites de fichiers sont 'quasiment' illimitees.
Malheureusement, dans le cas present, je suis tenu a Access. ET ... je ne connais pas encore toutes les Windev's stories. Il m'etonnerait qu'il n'y en ait pas !
Bonne soiree. Michel
-----Message d'origine----- Bonjour Michel!
Le probleme que vous evoquez n'est pas simple, mais en general, on parvient
a obtenir une sorte d'indirection en nommant les elements dans la collection
que l'on veut atteindre. Par exemple, au lieu de rst! MonChamp, on peut
utiliser rst.fields("MonChamp"), ce qui ouvre la porte a Dim strChamp as string strChamp = "MonChamp" rst.fields(strChamp) = blah-blah-blah...
Voyez la documentation d'Access, et celle d'ADO (et eventuellement DAO),
elles montrent les collections qui sont disponibles pour acceder aux
elements d'Access.
J'espere que ca vous est de quelque utilite...
-- Daniel :-)
Computing Technologies International - www.computing- tech.com - We
provide solutions...
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas
encore explore.
Pour info, puisqu'il en est de temps en temps question,
Windev dispose d'operateurs d'indirection.
Et en sus, les capacites de fichiers sont 'quasiment'
illimitees.
Malheureusement, dans le cas present, je suis tenu a
Access.
ET ... je ne connais pas encore toutes les Windev's
stories. Il m'etonnerait qu'il n'y en ait pas !
Bonne soiree.
Michel
-----Message d'origine-----
Bonjour Michel!
Le probleme que vous evoquez n'est pas simple, mais en
general, on parvient
a obtenir une sorte d'indirection en nommant les elements
dans la collection
que l'on veut atteindre. Par exemple, au lieu de rst!
MonChamp, on peut
utiliser rst.fields("MonChamp"), ce qui ouvre la porte a
Dim strChamp as string
strChamp = "MonChamp"
rst.fields(strChamp) = blah-blah-blah...
Voyez la documentation d'Access, et celle d'ADO (et
eventuellement DAO),
elles montrent les collections qui sont disponibles pour
acceder aux
elements d'Access.
J'espere que ca vous est de quelque utilite...
--
Daniel :-)
Computing Technologies International - www.computing-
tech.com - We
C'est effectivement quelque chose que je n'avais pas encore explore.
Pour info, puisqu'il en est de temps en temps question, Windev dispose d'operateurs d'indirection. Et en sus, les capacites de fichiers sont 'quasiment' illimitees.
Malheureusement, dans le cas present, je suis tenu a Access. ET ... je ne connais pas encore toutes les Windev's stories. Il m'etonnerait qu'il n'y en ait pas !
Bonne soiree. Michel
-----Message d'origine----- Bonjour Michel!
Le probleme que vous evoquez n'est pas simple, mais en general, on parvient
a obtenir une sorte d'indirection en nommant les elements dans la collection
que l'on veut atteindre. Par exemple, au lieu de rst! MonChamp, on peut
utiliser rst.fields("MonChamp"), ce qui ouvre la porte a Dim strChamp as string strChamp = "MonChamp" rst.fields(strChamp) = blah-blah-blah...
Voyez la documentation d'Access, et celle d'ADO (et eventuellement DAO),
elles montrent les collections qui sont disponibles pour acceder aux
elements d'Access.
J'espere que ca vous est de quelque utilite...
-- Daniel :-)
Computing Technologies International - www.computing- tech.com - We
provide solutions...
Daniel Carollo
Bonjour Michel!
"Michel Gesnot" wrote in message news:c17e01c43843$a2440eb0$
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas encore explore.
C'est tres utile pour faire des traitements sur les controles dans les formulaires. Pour peu que l'on ait pris un peu de soin au moment de nomer les controles, il est possible de faire pas mal de choses simplement avec des Case Mid(cntrl.name,4,2) par exemple.
Si c'est necessaire au niveau des champs, cela indique probablement qu'une autre structure des tables etait possible. J'ai repris une usine a gaz dernierement ou il y avait justement ce genre de chose qui etait fait en code. En modifiant la structure de la table (informations stockees verticalement dans une table separee plutot qu'horizontalement dans des champs pas toujours renseignes, a concatener plus tard), je suis parvenu a faire tous les traitements a l'aide de requetes.
Pour info, puisqu'il en est de temps en temps question, Windev dispose d'operateurs d'indirection. Et en sus, les capacites de fichiers sont 'quasiment' illimitees.
Peut-etre bien. SQL Server permet de stocker des TB de donnees...
Malheureusement, dans le cas present, je suis tenu a Access. ET ... je ne connais pas encore toutes les Windev's stories. Il m'etonnerait qu'il n'y en ait pas !
C'est le probleme quand on change d'outil: on a encore l'esprit moule a la facon de faire de l'outil que l'on vient de quitter. Comme toutes les technologies, elles ont ete creees pour repondre a un besoin. Lorsque ce besoin evolue, il est parfois difficile de faire evoluer les outils. A mon avis, on fait difficilement mieux que Dot Net Framework pour le developpement. Liberte de language (entre autres)...
Bonne soiree.
Ah, non, la c'est la journee qui commence...
Bien le bonjour chez vous ;-)
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
Bonjour Michel!
"Michel Gesnot" wrote in message
news:c17e01c43843$a2440eb0$a601280a@phx.gbl...
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas
encore explore.
C'est tres utile pour faire des traitements sur les controles dans les
formulaires. Pour peu que l'on ait pris un peu de soin au moment de nomer
les controles, il est possible de faire pas mal de choses simplement avec
des Case Mid(cntrl.name,4,2) par exemple.
Si c'est necessaire au niveau des champs, cela indique probablement qu'une
autre structure des tables etait possible. J'ai repris une usine a gaz
dernierement ou il y avait justement ce genre de chose qui etait fait en
code. En modifiant la structure de la table (informations stockees
verticalement dans une table separee plutot qu'horizontalement dans des
champs pas toujours renseignes, a concatener plus tard), je suis parvenu a
faire tous les traitements a l'aide de requetes.
Pour info, puisqu'il en est de temps en temps question,
Windev dispose d'operateurs d'indirection.
Et en sus, les capacites de fichiers sont 'quasiment'
illimitees.
Peut-etre bien. SQL Server permet de stocker des TB de donnees...
Malheureusement, dans le cas present, je suis tenu a
Access.
ET ... je ne connais pas encore toutes les Windev's
stories. Il m'etonnerait qu'il n'y en ait pas !
C'est le probleme quand on change d'outil: on a encore l'esprit moule a la
facon de faire de l'outil que l'on vient de quitter.
Comme toutes les technologies, elles ont ete creees pour repondre a un
besoin. Lorsque ce besoin evolue, il est parfois difficile de faire evoluer
les outils. A mon avis, on fait difficilement mieux que Dot Net Framework
pour le developpement. Liberte de language (entre autres)...
Bonne soiree.
Ah, non, la c'est la journee qui commence...
Bien le bonjour chez vous ;-)
--
Daniel :-)
Computing Technologies International - www.computing-tech.com - We
provide solutions...
"Michel Gesnot" wrote in message news:c17e01c43843$a2440eb0$
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas encore explore.
C'est tres utile pour faire des traitements sur les controles dans les formulaires. Pour peu que l'on ait pris un peu de soin au moment de nomer les controles, il est possible de faire pas mal de choses simplement avec des Case Mid(cntrl.name,4,2) par exemple.
Si c'est necessaire au niveau des champs, cela indique probablement qu'une autre structure des tables etait possible. J'ai repris une usine a gaz dernierement ou il y avait justement ce genre de chose qui etait fait en code. En modifiant la structure de la table (informations stockees verticalement dans une table separee plutot qu'horizontalement dans des champs pas toujours renseignes, a concatener plus tard), je suis parvenu a faire tous les traitements a l'aide de requetes.
Pour info, puisqu'il en est de temps en temps question, Windev dispose d'operateurs d'indirection. Et en sus, les capacites de fichiers sont 'quasiment' illimitees.
Peut-etre bien. SQL Server permet de stocker des TB de donnees...
Malheureusement, dans le cas present, je suis tenu a Access. ET ... je ne connais pas encore toutes les Windev's stories. Il m'etonnerait qu'il n'y en ait pas !
C'est le probleme quand on change d'outil: on a encore l'esprit moule a la facon de faire de l'outil que l'on vient de quitter. Comme toutes les technologies, elles ont ete creees pour repondre a un besoin. Lorsque ce besoin evolue, il est parfois difficile de faire evoluer les outils. A mon avis, on fait difficilement mieux que Dot Net Framework pour le developpement. Liberte de language (entre autres)...
Bonne soiree.
Ah, non, la c'est la journee qui commence...
Bien le bonjour chez vous ;-)
-- Daniel :-)
Computing Technologies International - www.computing-tech.com - We provide solutions...
Michel Gesnot
Bonjour Daniel.
En fait, mon probleme se focalise uniquement sur la construction des noms des variables, meme si j'avais generalise la question par souci de clarte.
J'utilise de fait les index de collection de temps a autre, mais suite a votre message, je pensais avoir neglige un acces a une hypothetique collection des variables VB d'une application. Si cette collection existe, elle ne nous est pas accessible.
La structuration des noms n'est pas relevante ici parce qu'il s'agit de donnees non hierarchisees et refletant deja une certaine compilation d'elements de base.
Nous recevons sur un CD un lot de petits fichiers textes zippes comprenant eux-memes de 1 a 10 items, ces items consistant en 2 a 3 chaines de caracteres de longueur variable regroupant de 150 à 1200 rubriques/lignes de donnees (numero de la donnee, contraintes eventuelles, les 6 derniers releves/compilations annuels). Plus un fichier index qui permet de savoir dans quel fichier zippe se trouve chaque item.
Il faut donc gerer le rapatriement de masse ou individuel a la demande et reformater les donnees. Classique, bouffeur de temps, et sans probleme particulier au niveau logique ou programmation.
Et apres cela, nous avons des donnees appelees L0001 a L1200, que nous pouvons regrouper par categories mais sans impact pour le traitement.
Et donc, comme toujours : - stats horizontales : n/n-1, n/n-3, n/n-5 en valeur et en % - operations (+ / -) verticales + le comparatif annuel ci- dessus - ratios, cad idem que ci-dessus mais avec des operations arithmetiques en numerateur et denominateur.
Afficher ou imprimer les infos de bases et meme les stats horizontales avec ou sans regroupement et extractions ne pose aucun probleme et ne demande que l'ecriture des requetes ad-hoc.
Par contre, gerer le code et l'affichage/impression des stats verticales et des ratios, c'est 6-7 colonnes dont la première en etiquette, le tout sur un nombre important de lignes. Cela garantit des erreurs dans le code, un suivi et des modifs fastidieux et toujours sujets a caution. Et qui sait ce que l'avenir nous reserve ?
Donc l'idee est de creer un fichier 'Traitements' qui reprend - la reference d'appel d'un traitemnt - les contraintes de ce traitement - son numerateur - son denominateur s'il s'agit d'un ratio - son format d'affichage le tout a la disposition d'une fonction a ecrire. Ca fonctionne, avec Eval.
Le tout est de passer la/les Lnnnnn a la fonction et de permettre a celle-ci de traiter le petit tableau de 6 valeurs, donc de contruire ce nom et notamment les indices.
A partir de la, - soit des fichiers 'Layout' d'impression/affichage permettent de tout gérer sans souci particulier et meme de generer des rapports specifiques a la demande. - soit des rapports et formulaires classiques dans lesquels il suffirait de coder l'etiquette tete de ligne et d'utiliser la propriete Tag de celle-ci pour alimenter le traitement, ce que nous faisons deja egalement.
On peut evidemment imaginer une grande table de 1200 lignes, mais il est prevu d'introduire une 3e dimension pour classement/comparatifs intra-categoriels... Donc, nous gerons la memoire a l'economie.
Le but est donc vraiment de sortir une application propre, facile a maintenir, facile a reprendre et sur PC.
Et la limite de cette histoire est l'indirection, a moins que j'aie quelque part une limite personnelle que je n'ai pas encore apercue !!
Enfin, cela viendra bien un jour ou l'autre. Et, en attendant on avance en essayant de ne pas faire des trucs a jeter a la poubelle des qu'une idee de genie nous aura ete donnee. Et on compte un peu sur vous aussi !!
Merci M. Gesnot
-----Message d'origine----- Bonjour Michel!
"Michel Gesnot" wrote in message news:c17e01c43843$a2440eb0$
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas encore explore.
C'est tres utile pour faire des traitements sur les controles dans les
formulaires. Pour peu que l'on ait pris un peu de soin au moment de nomer
les controles, il est possible de faire pas mal de choses simplement avec
des Case Mid(cntrl.name,4,2) par exemple.
Si c'est necessaire au niveau des champs, cela indique probablement qu'une
autre structure des tables etait possible. J'ai repris une usine a gaz
dernierement ou il y avait justement ce genre de chose qui etait fait en
code. En modifiant la structure de la table (informations stockees
verticalement dans une table separee plutot qu'horizontalement dans des
champs pas toujours renseignes, a concatener plus tard), je suis parvenu a
faire tous les traitements a l'aide de requetes.
Bonjour Daniel.
En fait, mon probleme se focalise uniquement sur la
construction des noms des variables, meme si j'avais
generalise la question par souci de clarte.
J'utilise de fait les index de collection de temps a
autre, mais suite a votre message, je pensais avoir
neglige un acces a une hypothetique collection des
variables VB d'une application.
Si cette collection existe, elle ne nous est pas
accessible.
La structuration des noms n'est pas relevante ici parce
qu'il s'agit de donnees non hierarchisees et refletant
deja une certaine compilation d'elements de base.
Nous recevons sur un CD un lot de petits fichiers textes
zippes comprenant eux-memes de 1 a 10 items, ces items
consistant en 2 a 3 chaines de caracteres de longueur
variable regroupant de 150 à 1200 rubriques/lignes de
donnees (numero de la donnee, contraintes eventuelles, les
6 derniers releves/compilations annuels). Plus un fichier
index qui permet de savoir dans quel fichier zippe se
trouve chaque item.
Il faut donc gerer le rapatriement de masse ou individuel
a la demande et reformater les donnees.
Classique, bouffeur de temps, et sans probleme particulier
au niveau logique ou programmation.
Et apres cela, nous avons des donnees appelees L0001 a
L1200, que nous pouvons regrouper par categories mais sans
impact pour le traitement.
Et donc, comme toujours :
- stats horizontales : n/n-1, n/n-3, n/n-5 en valeur et en
%
- operations (+ / -) verticales + le comparatif annuel ci-
dessus
- ratios, cad idem que ci-dessus mais avec des operations
arithmetiques en numerateur et denominateur.
Afficher ou imprimer les infos de bases et meme les stats
horizontales avec ou sans regroupement et extractions ne
pose aucun probleme et ne demande que l'ecriture des
requetes ad-hoc.
Par contre, gerer le code et l'affichage/impression des
stats verticales et des ratios, c'est 6-7 colonnes dont la
première en etiquette, le tout sur un nombre important de
lignes. Cela garantit des erreurs dans le code, un suivi
et des modifs fastidieux et toujours sujets a caution.
Et qui sait ce que l'avenir nous reserve ?
Donc l'idee est de creer un fichier 'Traitements'
qui reprend
- la reference d'appel d'un traitemnt
- les contraintes de ce traitement
- son numerateur
- son denominateur s'il s'agit d'un ratio
- son format d'affichage
le tout a la disposition d'une fonction a ecrire.
Ca fonctionne, avec Eval.
Le tout est de passer la/les Lnnnnn a la fonction et de
permettre a celle-ci de traiter le petit tableau de 6
valeurs, donc de contruire ce nom et notamment les indices.
A partir de la,
- soit des fichiers 'Layout' d'impression/affichage
permettent de tout gérer sans souci particulier et meme de
generer des rapports specifiques a la demande.
- soit des rapports et formulaires classiques dans
lesquels il suffirait de coder l'etiquette tete de ligne
et d'utiliser la propriete Tag de celle-ci pour alimenter
le traitement, ce que nous faisons deja egalement.
On peut evidemment imaginer une grande table de 1200
lignes, mais il est prevu d'introduire une 3e dimension
pour classement/comparatifs intra-categoriels...
Donc, nous gerons la memoire a l'economie.
Le but est donc vraiment de sortir une application propre,
facile a maintenir, facile a reprendre et sur PC.
Et la limite de cette histoire est l'indirection, a moins
que j'aie quelque part une limite personnelle que je n'ai
pas encore apercue !!
Enfin, cela viendra bien un jour ou l'autre.
Et, en attendant on avance en essayant de ne pas faire des
trucs a jeter a la poubelle des qu'une idee de genie nous
aura ete donnee.
Et on compte un peu sur vous aussi !!
Merci
M. Gesnot
-----Message d'origine-----
Bonjour Michel!
"Michel Gesnot" wrote in message
news:c17e01c43843$a2440eb0$a601280a@phx.gbl...
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas
encore explore.
C'est tres utile pour faire des traitements sur les
controles dans les
formulaires. Pour peu que l'on ait pris un peu de soin au
moment de nomer
les controles, il est possible de faire pas mal de choses
simplement avec
des Case Mid(cntrl.name,4,2) par exemple.
Si c'est necessaire au niveau des champs, cela indique
probablement qu'une
autre structure des tables etait possible. J'ai repris
une usine a gaz
dernierement ou il y avait justement ce genre de chose
qui etait fait en
code. En modifiant la structure de la table (informations
stockees
verticalement dans une table separee plutot
qu'horizontalement dans des
champs pas toujours renseignes, a concatener plus tard),
je suis parvenu a
En fait, mon probleme se focalise uniquement sur la construction des noms des variables, meme si j'avais generalise la question par souci de clarte.
J'utilise de fait les index de collection de temps a autre, mais suite a votre message, je pensais avoir neglige un acces a une hypothetique collection des variables VB d'une application. Si cette collection existe, elle ne nous est pas accessible.
La structuration des noms n'est pas relevante ici parce qu'il s'agit de donnees non hierarchisees et refletant deja une certaine compilation d'elements de base.
Nous recevons sur un CD un lot de petits fichiers textes zippes comprenant eux-memes de 1 a 10 items, ces items consistant en 2 a 3 chaines de caracteres de longueur variable regroupant de 150 à 1200 rubriques/lignes de donnees (numero de la donnee, contraintes eventuelles, les 6 derniers releves/compilations annuels). Plus un fichier index qui permet de savoir dans quel fichier zippe se trouve chaque item.
Il faut donc gerer le rapatriement de masse ou individuel a la demande et reformater les donnees. Classique, bouffeur de temps, et sans probleme particulier au niveau logique ou programmation.
Et apres cela, nous avons des donnees appelees L0001 a L1200, que nous pouvons regrouper par categories mais sans impact pour le traitement.
Et donc, comme toujours : - stats horizontales : n/n-1, n/n-3, n/n-5 en valeur et en % - operations (+ / -) verticales + le comparatif annuel ci- dessus - ratios, cad idem que ci-dessus mais avec des operations arithmetiques en numerateur et denominateur.
Afficher ou imprimer les infos de bases et meme les stats horizontales avec ou sans regroupement et extractions ne pose aucun probleme et ne demande que l'ecriture des requetes ad-hoc.
Par contre, gerer le code et l'affichage/impression des stats verticales et des ratios, c'est 6-7 colonnes dont la première en etiquette, le tout sur un nombre important de lignes. Cela garantit des erreurs dans le code, un suivi et des modifs fastidieux et toujours sujets a caution. Et qui sait ce que l'avenir nous reserve ?
Donc l'idee est de creer un fichier 'Traitements' qui reprend - la reference d'appel d'un traitemnt - les contraintes de ce traitement - son numerateur - son denominateur s'il s'agit d'un ratio - son format d'affichage le tout a la disposition d'une fonction a ecrire. Ca fonctionne, avec Eval.
Le tout est de passer la/les Lnnnnn a la fonction et de permettre a celle-ci de traiter le petit tableau de 6 valeurs, donc de contruire ce nom et notamment les indices.
A partir de la, - soit des fichiers 'Layout' d'impression/affichage permettent de tout gérer sans souci particulier et meme de generer des rapports specifiques a la demande. - soit des rapports et formulaires classiques dans lesquels il suffirait de coder l'etiquette tete de ligne et d'utiliser la propriete Tag de celle-ci pour alimenter le traitement, ce que nous faisons deja egalement.
On peut evidemment imaginer une grande table de 1200 lignes, mais il est prevu d'introduire une 3e dimension pour classement/comparatifs intra-categoriels... Donc, nous gerons la memoire a l'economie.
Le but est donc vraiment de sortir une application propre, facile a maintenir, facile a reprendre et sur PC.
Et la limite de cette histoire est l'indirection, a moins que j'aie quelque part une limite personnelle que je n'ai pas encore apercue !!
Enfin, cela viendra bien un jour ou l'autre. Et, en attendant on avance en essayant de ne pas faire des trucs a jeter a la poubelle des qu'une idee de genie nous aura ete donnee. Et on compte un peu sur vous aussi !!
Merci M. Gesnot
-----Message d'origine----- Bonjour Michel!
"Michel Gesnot" wrote in message news:c17e01c43843$a2440eb0$
Merci Daniel,
C'est effectivement quelque chose que je n'avais pas encore explore.
C'est tres utile pour faire des traitements sur les controles dans les
formulaires. Pour peu que l'on ait pris un peu de soin au moment de nomer
les controles, il est possible de faire pas mal de choses simplement avec
des Case Mid(cntrl.name,4,2) par exemple.
Si c'est necessaire au niveau des champs, cela indique probablement qu'une
autre structure des tables etait possible. J'ai repris une usine a gaz
dernierement ou il y avait justement ce genre de chose qui etait fait en
code. En modifiant la structure de la table (informations stockees
verticalement dans une table separee plutot qu'horizontalement dans des
champs pas toujours renseignes, a concatener plus tard), je suis parvenu a
