Diesel DWGPREFIX et publication de présentations

[sdelesse]

Bonjour,

Dans un cartouche, j'intègre une ligne de texte avec des informations sur un projet et une expression DIESEL suivante :
-> $(substr, $(getvar, dwgprefix),xx,yy)

Cela m'extrait 8 caractères d'un numéro de dossier. A l'écran, ça marche parfaitement, mais quand je lance une publication de mes présentations, cette valeur affiche les yy caractères issus du dossier temporaire ".../AppData/Temp/AcPublish" . A l'inverse, si j'imprime simplement ma présentation (Ctrl P) la variable DWGPREFIX se comporte correctement et le nom de dossier apparait correctement.

Comment remédier à cela ??

Merci de votre aide.

[Caderix]

Bonjour, 

Effectivement, c'est bizarre.

Je pense que c'est un bug ou plutôt une situation non prévue. C'est un cas assez particulier, mais c'est vrai que le résultat n'est pas celui attendu.

Je vais faire un rapport de bug, après je ne garantit rien.

[sdelesse]

Bonjour Eric,

Merci pour ce retour. Outre le problème lui-même, je vois souvent passer des fichiers PDF de plusieurs pages venant d'entreprises extérieures qui affichent dans leur cartouche le nom du dossier dans lequel se trouve leur fichier. Comment font ces entreprises ??? J'ai l'impression de passer à côté d'une solution simple ou évidente mais je ne vois pas laquelle.

Merci...

[Caderix]

Je pense qu'ils mettent ce champ :

[sdelesse]

C'est une option que j'avais également envisagée mais elle ne permet pas de tronquer une partie seulement de ce champs, puisqu'il est affiché en totalité... L'arborescence interne devant être masquée...

[CADaSchtroumpf]

Bonjour,

Tu dis employer une expression diesel, mais quand j'ouvre ton dessin exemple et que je sélectionne le champ pour le modifier, ce n'est pas une expression diesel que je trouve mais l'interrogation d'une variable système!

Essayes de vraiment mettre l'expression diesel que tu suggérais, peut êtque ça n'auras pas le même comportement.

Le diesel est un interpreteur de chaine...

[Caderix]

J'ai testé avec l'expression diesel et ça fait pareil.

[sdelesse]

Oui en effet le résultat est le même. Voir pièces jointes...!

[CADaSchtroumpf]

---

@sdelesse  a écrit :

Bonjour Eric,

Merci pour ce retour. Outre le problème lui-même, je vois souvent passer des fichiers PDF de plusieurs pages venant d'entreprises extérieures qui affichent dans leur cartouche le nom du dossier dans lequel se trouve leur fichier. Comment font ces entreprises ??? J'ai l'impression de passer à côté d'une solution simple ou évidente mais je ne vois pas laquelle.

Merci...

---

J'ai pas testé, mais peut être utilisent ils la commande RTEXT (option diesel) des ExpressTools? A voir!

[sdelesse]

Non, le résultat est le même, je viens d'essayer.

[O_Eckmann · Accepted solution]

Bonjour,

Essayer d'enlever 4 à la valeur de FIELDEVAL pour ne pas mettre à jour les champ pendant l'impression.

Mettre 27 au lieu de 31.

Il suffira de penser à faire un REGEN avant de lancer la publication.

Olivier

[sdelesse]

Merci Olivier, cela peut faire l'affaire en attendant une solution moins risquée (regen avant chaque impression, c'est un peu hasardeux).

[O_Eckmann]

Normalement je fais toujours une sauvegarde avant de publier (on ne sait jamais si ça plantait), donc les champs sont mis à jour, pas besoin de REGEN.

Olivier

[reb_c1]

Bonjour,

En expression DIESEL, le problème de certaines variables est dû AU MAUVAIS CHOIX DE SEPARATEUR des dossiers affiché dans la variable !!!!!!

En effet, le   \  (anti slash) agit comme une PAUSE lorsqu'on utilise ce DIESEL dans une MACRO !

Il faudrait que pour TOUS LES CHEMINS, ils soient affichés avec le   /   (slash)

Christian

[sdelesse]

C'est vrai, néanmoins ce n'est pas là que réside la solution à mon problème dans la mesure où le simple blocage de l'évaluation de champs lors de l'impression permet à l'expression diesel de fonctionner correctement, malgré un chemin de dossier composé de \ pour les séparateurs.

Le problème réside dans le fait que la variable DWGPREFIX change de valeur lors de la publication...

[Anonymous]

Salut Reb.

On ne devrait pas remplacer le "\" par un "//" dans les chemins ?

[didier_lourdelle]

Bonjour

AutoCAD 2020 reproduction du problème.

AutoCAD 2018 sa fonctionne correctement.

La solution de Olivier reste un contournement, ça doit être un bug de plus au final.

Qui pourrait confirmer ?