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

[VBA 2000-2003] FitText dans un tableau

23 réponses
Avatar
Lotre
Bonjour,

Je vais tenter d'être clair et précis, ce qui va forcément être un peu
long.

Je suis en train de finaliser un document "un peu compliqué" (pour moi
au moins) avec pas mal de macros. Parmi ces macros, certaines
construisent des tableaux dans le document. Les macros fixent les
dimensions du tableau ( hauteur des lignes et largeur des cellules).
Les cellules sont prévues pour recevoir du texte de taille assez
variable... Mais c'est prévu pour occuper une seule ligne. Cependant,
Il arrive qu'avec la police et la taille fixée au départ, un retour de
ligne augmente la hauteur d'un ligne ce qui met en l'air la mise en
page... Je pourrais choisir un police plus petite pour que cela ne se
produise pas mais ces cas là sont rares et le reste du temps, la
police est "bien adaptée"...

Je pensais que la propriété FitText d'une cellule conviendrait mais
lorsque le texte est cours, il est étiré pour remplir la cellule en
largeur et c'est particulièrement moche.

J'ai donc fait une Sub qui ne met FitText que si "nécessaire" ... la
vérification est pour le moment basée sur le nb de caractères mais ce
paramètre n'est pas très pertinent puisque les caractères sont de
largeur variable. Je suis donc obligé de minorer assez grossièrement
pour que le pb ne se produise pas...


Au départ je pensais tester la hauteur de la ligne pour repérer les pb
mais j'ai constaté que la propriété Height n'est pas impactée par le
changement de hauteur lorsque le texte est "trop long"... de plus cela
ne me dirait pas quelle cellule est à l'origine du changement.

donc ... voilà ma question ?

Comment connaitre concrètement le nombre réel de lignes d'une cellule
?
ou alors
comment détecter la présence d'un saut de ligne dans une cellule ?


Merci d'avance pour vos lumières,
bien cordialement,

HB

10 réponses

1 2 3
Avatar
Geo
Bonjour
[ Cette réponse est faite sur le forum public Word :
news://msnews.microsoft.com/microsoft.public.fr.word ]



Merci pour vos variantes, quand on a la tête dans le guidon, on oublie
parfois de regarder où on va.

Une question cependant :
Même en points, la position doit être identique sur une même "ligne réelle" non ?



Oui, mais en faisant des tests je me suis aperçu qu'elle pouvait
différer d'un point ou deux. Je suppose que la position est prise sur
la ligne où sont "posées" les lettres. Donc quand on réduit la taille
des lettres la position change un peu. C'est la raison pour laquelle
j'ai utilisé la différence entre les deux positions.

Normalement, une cellule ne pourra donc pas être "à cheval" sur deux pages...
La fin du contenu d'une cellule est forcément sur la même page et après le début.



Vous avez raison de soulever ce point que j'ai omis de traiter.
Pour en être certain, il faut interdire le fractionnement au moyen de
la propriété AllowBreakAcrossPages.

Quel est le problème que je n'envisage pas ?



Ca fait déjà un bon tour du sujet.

Bon courage.

--
A+
Avatar
Geo
Re

N'oubliez pas qu'il faut être en mode page.

--
A+
Avatar
Lotre
Bonjour,

Après plusieurs tests je vais "modifier" la sub AJUSTE1
car je me suis rendu compte que dans certains cas
le passage à la police inférieure de 0.5 avec -0.5 pour l'espace
était nettement excessif.

J'ai eu le cas suivant :
avec police 10 et espace -0.5 -> encore trop long
avec police 9.5 et _donc_ espace -0.5 -> soudain trop petit ..
mais "police 9.5 espace normal" était déjà bon ...

En fait je vais faire une boucle unique un peu différente
pour remettre l'espace à zéro quand on diminue la police...

A+
et encore merci pour la piste déterminante,


HB
Avatar
Geo
Bonjour

Après plusieurs tests je vais "modifier" la sub AJUSTE1
car je me suis rendu compte que dans certains cas
le passage à la police inférieure de 0.5 avec -0.5 pour l'espace
était nettement excessif.

J'ai eu le cas suivant :
avec police 10 et espace -0.5 -> encore trop long
avec police 9.5 et _donc_ espace -0.5 -> soudain trop petit ..
mais "police 9.5 espace normal" était déjà bon ...

En fait je vais faire une boucle unique un peu différente
pour remettre l'espace à zéro quand on diminue la police...



C'est vrai qu'on peut imaginer des tas de combinaisons.
Espace à 0 risque d'être trop après coup, donc, une fois qu'on est
arrivé à une seule ligne, ré-augmenter progressivement l'espace jusqu'à
remplir la ligne.
En fait, aller jusqu'au débordement et refaire un pas en arrière.
Votre solution de n'appliquer le Fit text que lorsqu'il y a plusieurs
lignes me paraissait intéressante.
Le résultat ne vous plaît pas ?

et encore merci pour la piste déterminante,



Je vais finir par avoir de la matière pour faire un bouquin sur le vba
Word. :-)

--
A+
Avatar
Lotre
Geo wrote:
Bonjour



(...)
Votre solution de n'appliquer le Fit text que lorsqu'il y a
plusieurs
lignes me paraissait intéressante.
Le résultat ne vous plaît pas ?




C'est de loin le plus performant ( ratio temps / résultat )
et comme le document peut contenir pas mal de cellules
c'est la solution retenue.

Ceci étant, histoire d'enrichir mes connaissances,
je creuse quand même les autres pistes pour voir les possibilités...
J'ai noté qu'effectivement, on peut avoir des écart curieux entre
posMin initialisé
et posmax qui change à chaque tour.

En fait la position relative du début change légèrement aussi quand la
police change.
C'est lié au fait que dans les tableaux fabriqués par les macros, j'ai
choisi de centrer le texte verticalement...
donc réduire la taille fait remonter le texte...

Cela donne, quand tout est enfin sur la même ligne des écarts
posmax - posmin négatifs

J'ai voulu alors re-définir aussi posmin après chaque modif de la
police mais je n'arrive pas à remettre simplement le point d'insertion
au début, ou alors, le .endKey suivant ne va plus à la fin du text de
la cellule ... Les déplacements dans un tableau sans quitter la
cellule restent des choses délicates ... et les exemples de l'aide
intégrée peu explicite à ce propos ;o)

mais bon ... ce n'est pas grave... je passe maintenant à la suite du
projet...

Merci encore,

HB
Avatar
Geo
Bonjour

Les déplacements dans un tableau
sans quitter la cellule restent des choses délicates ... et les exemples de l'aide
intégrée peu explicite à ce propos ;o)



D'accord sur les deux points.
Pour déplacer la sélection on peut s'appuyer sur le range de la cellule
:

PosD = Cellule.Range.Start
PosF = Cellule.Range.End - 1
ActiveDocument.Range(Start:=PosD, End:=PosD).Select
PosMin = Selection.Information(wdVerticalPositionRelativeToPage)
ActiveDocument.Range(Start:=PosF, End:=PosF).Select
PosMax = Selection.Information(wdVerticalPositionRelativeToPage)

J'avoue ne pas savoir pourquoi il faut faire le -1 sur PosF.

Bon courage pour la suite.

--
A+
Avatar
Lotre
Bonjour,

Geo wrote:
Bonjour


PosD = Cellule.Range.Start
PosF = Cellule.Range.End - 1
ActiveDocument.Range(Start:=PosD, End:=PosD).Select
PosMin = Selection.Information(wdVerticalPositionRelativeToPage)
ActiveDocument.Range(Start:=PosF, End:=PosF).Select
PosMax = Selection.Information(wdVerticalPositionRelativeToPage)



C'est rigolo ;o)

la position tient compte du "sens" dans lequel on définit le "range"
j'ignorais

Effectivement c'est une solution ;o)


J'avoue ne pas savoir pourquoi il faut faire le -1 sur PosF.




Parfois il faut renoncer à comprendre et se contenter de savoir...

HB
Avatar
Geo
Bonsoir

la position tient compte du "sens" dans lequel on définit le "range"



Non, non.
ActiveDocument.Range(Start:=PosD, End:=PosD)
définit un range qui commence et finit au même endroit, ici : le début
de la cellule dont on a récupéré au préalable la position relative par
rapport au début du document (posD).
Et le Select positionne le point d'insertion à cet endroit, on voit
bien qu'il n'y a aucun texte de sélectionné.
Si on avait mis ActiveDocument.Range(Start:=PosD, End:=PosD+1).Select
le premier caractère de la cellule aurait été sélectionné.

ActiveDocument.Range(Start:=PosF, End:=PosF).Select
Positionne le point d'insertion à la fin du texte de la cellule.
Idem, on aurait mis :
ActiveDocument.Range(Start:=PosF-1, End:=PosF).Select
le dernier caractère aurait été sélectionné.
A noter que cette syntaxe n'est disponible qu'avec un objet Document,
ce qui explique qu'on ait utilisé les variables PosD et PosF.
Si on avait pu l'appliquer à un Range, on aurait fait :
cellule.range(Start:=1, End:=1), c'eût été plus simple

Parfois il faut renoncer à comprendre et se contenter de savoir...



Sage maxime.

Bonne soirée et merci à vous, votre question m'aura fait découvrir
quelques recoins inconnus.

--
A+
Avatar
Lotre
Bonsoir,

J'ai changé le titre du fil parce que là,
franchement, on est loin du fil initial.

Geo wrote:
Bonsoir

la position tient compte du "sens" dans lequel on définit le
"range"


Non, non.


(...)
Oh ... p.... ! j'avais lu en diagonale !

Puique c'est ainsi...
une question (encore ? !) :

Si je veux copier le contenu d'un tableau
dans un autre vide mais de forme identique
existe-t-il une méthode rapide
à part le bête balayage :

for i = 1 to L
for j = 1 to C
Tablo2.cell(i,j).range.text = _
Tablo1.cell(i,j).range.text
next j
next i

Merci d'avance
Avatar
Geo
Re
une question (encore ? !) :

Si je veux copier le contenu d'un tableau
dans un autre vide mais de forme identique
existe-t-il une méthode rapide
à part le bête balayage :

for i = 1 to L
for j = 1 to C
Tablo2.cell(i,j).range.text = _
Tablo1.cell(i,j).range.text
next j
next i



Là on ne recopie que le texte, pas la mise en forme.
Je tenterais bien un copier / coller, comme à la main
Qqch comme :
Tablo1.Range.Copy
Tablo2.Range.Paste
ou PasteSpecial selon les souhaits.

PS on peut faire une nouvelle conversation sur le sujet si vous le
souhaitez, ça permettra à d'autres de raccrocher.

--
A+
1 2 3