Je vous solicite de nouveau, par rapport =E0 une autre question pour
laquelle je n'ai pas encore trouv=E9 de solution.
Je suis charg=E9 de modifier une s=E9rie de mod=E8les de fusion dans lequel
se trouve r=E9p=E9ter des kyrielles de ligne du genre
{IF {MERGEFIELD Code} =3D "L001" {AUTOTEXT L001}}
{IF {MERGEFIELD Code} =3D "L002" {AUTOTEXT L002}}
{IF {MERGEFIELD Code} =3D "H001" {AUTOTEXT H001}}
etc...
=E7=E0 fonctionne mais il y a plus d'une cinquantaine de ligne comme cela,
et je trouve que :
1=2E c'est pas facile =E0 maintenir, c'est compl=E8tement ilisible
2=2E c'est pas tr=E8s efficace
3=2E Si la table des codes change, il faudra encore revenir sur tous les
documents dans lesquels cette s=E9quence est pr=E9sente.
J'ai essay=E9 de remplacer par
{AUTOTEXT {MERGEFIELD Code}}
Ce qui renvoye bien un r=E9sultat ... mais pas le bon !
J'ai essay=E9 aussi
{SET CodeLie {MERGEFIELD Code}}
{AUTOTEXT {MERGEFIELD CodeLie}}
Quelqu'un peut-il m'expliquer pourquoi cela ne fonctionne pas ?
Et mieux me donner une solution qui fonctionne ...
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
Anacoluthe
Bonjour !
'Wlad69' nous a écrit ...
J'ai essayé de remplacer par {AUTOTEXT {MERGEFIELD Code}} Ce qui renvoye bien un résultat ... mais pas le bon ! J'ai essayé aussi {SET CodeLie {MERGEFIELD Code}} {AUTOTEXT {MERGEFIELD CodeLie}} Quelqu'un peut-il m'expliquer pourquoi cela ne fonctionne pas ?
Ça ne fonctionne pas parce que le champ AUTOTEXT ne passe pas la fusion.
En matière de fusion il y a : - les champs qui 'passent' la fusion comme INCLUDETEXT , LINK etc ce qui veut dire qu'on retrouve le champ dans le document de fusion - les champs qui ne 'passent pas' la fusion comme IF , SET etc ce qui veut dire qu'ils sont 'déchampés' AVANT la fusion, certains sans mise à jour comme AUTOTEXT.
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra se contenter de la série des IF. Généralement la solution est ailleurs : vous écrivez un simple { MERGEFIELD Code } et la source de données relationnelle aura fait le reste.
Bien souvent ici le drame du publipostage tient à ce qu'on veut que Word TRAITE les données, alors que le but n'est que de fusionner des données dans des documents de fusion. Il suffit d'utiliser les bons outils de gestion de bases de données et de fournir les bonnes données à Word...
Anacoluthe « Dans limpossible fusion la confusion. » - Jacques LACAN
Bonjour !
'Wlad69' nous a écrit ...
J'ai essayé de remplacer par
{AUTOTEXT {MERGEFIELD Code}}
Ce qui renvoye bien un résultat ... mais pas le bon !
J'ai essayé aussi
{SET CodeLie {MERGEFIELD Code}}
{AUTOTEXT {MERGEFIELD CodeLie}}
Quelqu'un peut-il m'expliquer pourquoi cela ne fonctionne pas ?
Ça ne fonctionne pas parce que le champ AUTOTEXT ne passe pas la fusion.
En matière de fusion il y a :
- les champs qui 'passent' la fusion comme INCLUDETEXT , LINK etc
ce qui veut dire qu'on retrouve le champ dans le document de fusion
- les champs qui ne 'passent pas' la fusion comme IF , SET etc
ce qui veut dire qu'ils sont 'déchampés' AVANT la fusion, certains
sans mise à jour comme AUTOTEXT.
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra
se contenter de la série des IF. Généralement la solution est
ailleurs : vous écrivez un simple { MERGEFIELD Code } et la
source de données relationnelle aura fait le reste.
Bien souvent ici le drame du publipostage tient à ce qu'on veut que
Word TRAITE les données, alors que le but n'est que de fusionner
des données dans des documents de fusion. Il suffit d'utiliser
les bons outils de gestion de bases de données et de fournir
les bonnes données à Word...
Anacoluthe
« Dans limpossible fusion la confusion. »
- Jacques LACAN
J'ai essayé de remplacer par {AUTOTEXT {MERGEFIELD Code}} Ce qui renvoye bien un résultat ... mais pas le bon ! J'ai essayé aussi {SET CodeLie {MERGEFIELD Code}} {AUTOTEXT {MERGEFIELD CodeLie}} Quelqu'un peut-il m'expliquer pourquoi cela ne fonctionne pas ?
Ça ne fonctionne pas parce que le champ AUTOTEXT ne passe pas la fusion.
En matière de fusion il y a : - les champs qui 'passent' la fusion comme INCLUDETEXT , LINK etc ce qui veut dire qu'on retrouve le champ dans le document de fusion - les champs qui ne 'passent pas' la fusion comme IF , SET etc ce qui veut dire qu'ils sont 'déchampés' AVANT la fusion, certains sans mise à jour comme AUTOTEXT.
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra se contenter de la série des IF. Généralement la solution est ailleurs : vous écrivez un simple { MERGEFIELD Code } et la source de données relationnelle aura fait le reste.
Bien souvent ici le drame du publipostage tient à ce qu'on veut que Word TRAITE les données, alors que le but n'est que de fusionner des données dans des documents de fusion. Il suffit d'utiliser les bons outils de gestion de bases de données et de fournir les bonnes données à Word...
Anacoluthe « Dans limpossible fusion la confusion. » - Jacques LACAN
JièL
Hello
Il suffit d'utiliser les bons outils de gestion de bases de données et de fournir les bonnes données à Word...
des clous et un marteau en bref ! ;-))))))
-- JièL / Jean-Louis GOUBERT Là bas mieux qu'en face ;-) http://forums.offices.free.fr/ La NOUVELLE Faq Outlook est là : http://faq.outlook.free.fr/index.php Les stats de CDO : http://faq.outlook.free.fr/cdo/
Hello
Il suffit d'utiliser
les bons outils de gestion de bases de données et de fournir
les bonnes données à Word...
des clous et un marteau en bref ! ;-))))))
--
JièL / Jean-Louis GOUBERT
Là bas mieux qu'en face ;-) http://forums.offices.free.fr/
La NOUVELLE Faq Outlook est là : http://faq.outlook.free.fr/index.php
Les stats de CDO : http://faq.outlook.free.fr/cdo/
Il suffit d'utiliser les bons outils de gestion de bases de données et de fournir les bonnes données à Word...
des clous et un marteau en bref ! ;-))))))
-- JièL / Jean-Louis GOUBERT Là bas mieux qu'en face ;-) http://forums.offices.free.fr/ La NOUVELLE Faq Outlook est là : http://faq.outlook.free.fr/index.php Les stats de CDO : http://faq.outlook.free.fr/cdo/
Anacoluthe
Re !
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra se contenter de la série des IF.
Je viens d'avoir une idée, suite à une autre ficelle sur les événements de publipostage : avec WD2002 ou + , on pourrait mettre à jour l' AUTOTEXT à chaque enregistrement à l'aide de l'événement MailMergeBeforeRecordMerge
Private Sub wdApp_MailMergeBeforeRecordMerge(ByVal Doc As Document, _ Cancel As Boolean) Doc.Fields.Update End Sub
J'ai testé : ça marche ! Un { AUTOTEXT { Mergefield Code } } donne à la fusion le texte brut de chaque insertion automatique nommée 'code'
Ça ne retire rien à ce que je pense sur l'intérêt d'Access, Excel ou autres outils idoines pour traiter les données en amont de Word ;-)
Anacoluthe « Dans limpossible fusion la confusion. » - Jacques LACAN
Re !
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra
se contenter de la série des IF.
Je viens d'avoir une idée, suite à une autre ficelle sur les
événements de publipostage : avec WD2002 ou + , on pourrait
mettre à jour l' AUTOTEXT à chaque enregistrement à l'aide
de l'événement MailMergeBeforeRecordMerge
Private Sub wdApp_MailMergeBeforeRecordMerge(ByVal Doc As Document, _
Cancel As Boolean)
Doc.Fields.Update
End Sub
J'ai testé : ça marche !
Un { AUTOTEXT { Mergefield Code } } donne à la fusion le texte brut
de chaque insertion automatique nommée 'code'
Ça ne retire rien à ce que je pense sur l'intérêt d'Access, Excel
ou autres outils idoines pour traiter les données en amont de Word ;-)
Anacoluthe
« Dans limpossible fusion la confusion. »
- Jacques LACAN
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra se contenter de la série des IF.
Je viens d'avoir une idée, suite à une autre ficelle sur les événements de publipostage : avec WD2002 ou + , on pourrait mettre à jour l' AUTOTEXT à chaque enregistrement à l'aide de l'événement MailMergeBeforeRecordMerge
Private Sub wdApp_MailMergeBeforeRecordMerge(ByVal Doc As Document, _ Cancel As Boolean) Doc.Fields.Update End Sub
J'ai testé : ça marche ! Un { AUTOTEXT { Mergefield Code } } donne à la fusion le texte brut de chaque insertion automatique nommée 'code'
Ça ne retire rien à ce que je pense sur l'intérêt d'Access, Excel ou autres outils idoines pour traiter les données en amont de Word ;-)
Anacoluthe « Dans limpossible fusion la confusion. » - Jacques LACAN
Wlad69
On 13 mar, 21:11, Anacoluthe wrote:
Re !
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra se contenter de la série des IF.
Je viens d'avoir une idée, suite à une autre ficelle sur les événements de publipostage : avec WD2002 ou + , on pourrait mettre à jour l' AUTOTEXT à chaque enregistrement à l'aide de l'événement MailMergeBeforeRecordMerge
Private Sub wdApp_MailMergeBeforeRecordMerge(ByVal Doc As Document, _ Cancel As Boolean) Doc.Fields.Update End Sub
J'ai testé : ça marche ! Un { AUTOTEXT { Mergefield Code } } donne à la fusion le texte brut de chaque insertion automatique nommée 'code'
Ça ne retire rien à ce que je pense sur l'intérêt d'Access, Excel ou autres outils idoines pour traiter les données en amont de Word ;-)
Anacoluthe « Dans l'impossible fusion la confusion. » - Jacques LACAN
Bonjour,
Merci pour cette solution, mais compte tenu de la dimension de la structure dans laquelle je travaille; négocier le changement de version ne sera pas chose facile.
J'ai expérimenté une solution à base de INCLUDETEXT qui fonctionne. un truc du genre Un document nommé "liste libellés.doc" dans lequel chaque libellé à insérer est marqué par un signet. J'ai fait une macro pour automatiser la création de la cinquantaine de signet. Ensuite j'insère dans le document principal : {INCLUDETEXT "C:Cheminliste libellés.doc" {MERGEFIELD Code}}
Ce qui me gêne dans cette solution c'est que le champ subsite dans le document généré. D'où l'autre ficelle sur l' "exécution automatiq ue d'une macro lors de la fusion".
Pour en revenir au fond du problème, effectivement, je chercher à pallier l'insuffisance de données dans la source de fusion. En replaçant les choses dans ce contexte, je me demande si un champ DATABASE ne serait pas plus pratique. Qu'en penser vous ? Quelle type de base me conseillez-vous ? Un fichier Excel peut-il convenir ?
Cordialement,
Wlad69
On 13 mar, 21:11, Anacoluthe <nopub_anacolu...@Ouanadoo.fr> wrote:
Re !
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra
se contenter de la série des IF.
Je viens d'avoir une idée, suite à une autre ficelle sur les
événements de publipostage : avec WD2002 ou + , on pourrait
mettre à jour l' AUTOTEXT à chaque enregistrement à l'aide
de l'événement MailMergeBeforeRecordMerge
Private Sub wdApp_MailMergeBeforeRecordMerge(ByVal Doc As Document, _
Cancel As Boolean)
Doc.Fields.Update
End Sub
J'ai testé : ça marche !
Un { AUTOTEXT { Mergefield Code } } donne à la fusion le texte brut
de chaque insertion automatique nommée 'code'
Ça ne retire rien à ce que je pense sur l'intérêt d'Access, Excel
ou autres outils idoines pour traiter les données en amont de Word ;-)
Anacoluthe
« Dans l'impossible fusion la confusion. »
- Jacques LACAN
Bonjour,
Merci pour cette solution, mais compte tenu de la dimension de la
structure dans laquelle je travaille; négocier le changement de
version ne sera pas chose facile.
J'ai expérimenté une solution à base de INCLUDETEXT qui fonctionne.
un truc du genre
Un document nommé "liste libellés.doc" dans lequel chaque libellé à
insérer est marqué par un signet. J'ai fait une macro pour automatiser
la création de la cinquantaine de signet.
Ensuite j'insère dans le document principal :
{INCLUDETEXT "C:\Chemin\liste libellés.doc" {MERGEFIELD Code}}
Ce qui me gêne dans cette solution c'est que le champ subsite dans le
document généré. D'où l'autre ficelle sur l' "exécution automatiq ue
d'une macro lors de la fusion".
Pour en revenir au fond du problème, effectivement, je chercher à
pallier l'insuffisance de données dans la source de fusion. En
replaçant les choses dans ce contexte, je me demande si un champ
DATABASE ne serait pas plus pratique. Qu'en penser vous ?
Quelle type de base me conseillez-vous ? Un fichier Excel peut-il
convenir ?
Si vous souhaitez continuer à utiliser les AUTOTEXT, il faudra se contenter de la série des IF.
Je viens d'avoir une idée, suite à une autre ficelle sur les événements de publipostage : avec WD2002 ou + , on pourrait mettre à jour l' AUTOTEXT à chaque enregistrement à l'aide de l'événement MailMergeBeforeRecordMerge
Private Sub wdApp_MailMergeBeforeRecordMerge(ByVal Doc As Document, _ Cancel As Boolean) Doc.Fields.Update End Sub
J'ai testé : ça marche ! Un { AUTOTEXT { Mergefield Code } } donne à la fusion le texte brut de chaque insertion automatique nommée 'code'
Ça ne retire rien à ce que je pense sur l'intérêt d'Access, Excel ou autres outils idoines pour traiter les données en amont de Word ;-)
Anacoluthe « Dans l'impossible fusion la confusion. » - Jacques LACAN
Bonjour,
Merci pour cette solution, mais compte tenu de la dimension de la structure dans laquelle je travaille; négocier le changement de version ne sera pas chose facile.
J'ai expérimenté une solution à base de INCLUDETEXT qui fonctionne. un truc du genre Un document nommé "liste libellés.doc" dans lequel chaque libellé à insérer est marqué par un signet. J'ai fait une macro pour automatiser la création de la cinquantaine de signet. Ensuite j'insère dans le document principal : {INCLUDETEXT "C:Cheminliste libellés.doc" {MERGEFIELD Code}}
Ce qui me gêne dans cette solution c'est que le champ subsite dans le document généré. D'où l'autre ficelle sur l' "exécution automatiq ue d'une macro lors de la fusion".
Pour en revenir au fond du problème, effectivement, je chercher à pallier l'insuffisance de données dans la source de fusion. En replaçant les choses dans ce contexte, je me demande si un champ DATABASE ne serait pas plus pratique. Qu'en penser vous ? Quelle type de base me conseillez-vous ? Un fichier Excel peut-il convenir ?
