Positionner curseur sur une cellule sélectée Windows Excel VBA

je sais pas mais perso
quand je fait simplement cela a 2 zoom différents même si les résultats sont faux comme tu le prétends ou pas

Code:

---

1 2 3 4

with activewindow z=.zoom/100 .ActivePane.PointsToScreenPixelsX([D3].Width) - .ActivePane.PointsToScreenPixelsX(0)) / Z) / [D3].Width end with

---

et que je n'obtiens pas la même chose il est évident pour n'importe quel benets avec 2 neurones de comprendre que c'est "Z" qui est le responsable la bonne blague il y a que lui qui change

et la il est nullement question de rustine ,bateau du voisin, tour de taille du fistion ou largeur du string de la voisine

c'est purement simple a comprendre
et si ce même benet n'avais qu'une seul neurones
en testant cela il verrait que pointstoscreenpixels n'a aucun problème

Code:

---

1 2 3 4 5 6 7 8 9

Sub test_cursor_pos() For i = 80 To 150 position_curseur [C3], i Sleep 200 Next End Sub Function position_curseur(rng, i) With ActiveWindow: .Zoom = i: SetCursorPos .ActivePane.PointsToScreenPixelsX(rng.Left), .ActivePane.PointsToScreenPixelsY(rng.Top): End With End Function

---

t'es pas miro non ?
Pièce jointe 291744
et la ca démontre bien ce que je dis malgré le defaut d'affichage que provoque le zoom pointstoscreenpixel lui donne la vrai position ECRAN!!!! car la il n'y a aucune operation ou formule utilisant le zoom seulement les point left et top en pixels
et la tu peut pas dire le contraire c'est gros comme le nez au milieu de ta figure

Citation:

---

il est évident pour n'importe quel benets avec 2 neurones de comprendre que c'est "Z" qui est le responsable la bonne blague il y a que lui qui change

---

Non m'sieu !
Ce n'est pas "z", le responsable, mais l'inefficacité de la méthode PointsToScreenPixelsX à tenir inclure ce "z" dans ses calculs. Pour être plus précis: à savoir distinguer et utiliser séparément dans ses calculs la partie "fixe" (non soumise au zoom) de la seule soumise aux effets du zoom.
Tu me rends triste, sais-tu ?
J'espère que le nombre de "développeurs" comme toi n'est pas trop grand ...

Citation:

---

mais l'inefficacité de la méthode PointsToScreenPixelsX à tenir inclure ce "z" dans ses calculs

---

pour une fois nous somme d'accords sauf que c'est pas pour les même raisons

je maintient que si l'affichage avec zoom n'était pas faussé ca fonctionnerait au pixel près ce qui est logique d'ailleurs
puisque l'on obtient le coefficient pixel to point avec (ptscpxs(3)-ptscpxs(0))/3 en zoom 100 on devrait obtenir la même chose a tout les zooms en / par coeff zoom

ca ne le fait pas pour la simple et bonne raison que la partie que vaut ptscpxs(0) est faussé par le zoom


c'est pas compliqué
seulement c'est pas le cas et le ZOOM en est bien le responsable je triche pas les résultats sont largement visible dans les captures postées
je t'attriste et toi tu m'énerve a refuser de voir ce que je te montre en image +macro qui sont plus que parlantes

Citation:

---

ca ne le fait pas pour la simple et bonne raison que la partie que vaut ptscpxs(0) est faussé par le zoom

---

c'est la TA croyance.
Garde-la donc, hein ... :D

re
Je revient en hésitant un peu, le test PointsToScreenPixelsX ne tient pas compte du zoom et le test zoom ne tient pas compte de PointsToScreenPixelsX
juste sur la dernière phase les deux sont additionner.
Si me je suis planter ne m'en voulez pas merci, mais pour moi ça parait clair.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

Sub test_ppx() 'test PointsToScreenPixelsX lig = 1 For i = 1 To 100 lig = lig + 1 Cells(lig, 1) = ActiveWindow.ActivePane.PointsToScreenPixelsX(i) Cells(lig, 2).FormulaR1C1 = "=SUM(RC[-1]-R[-1]C[-1])" Next Range("A1").Value = "PointsToScreenPixelsX" Range("B1").Value = "Ecart" Range("B2").Value = "" Columns("A:H").ColumnWidth = 25 'test zoom lig = 1 For j = 50 To 150 lig = lig + 1 ActiveWindow.Zoom = j Cells(lig, 4) = 1 * ActiveWindow.Zoom / 100 Cells(lig, 5).FormulaR1C1 = "=SUM(RC[-1]-R[-1]C[-1])" Next ActiveWindow.Zoom = 100 Range("D1").Value = "Zoom" Range("E1").Value = "Ecart " Range("E2").Value = "" 'test PointsToScreenPixelsX_x_zoom lig = 1 For k = 50 To 150 lig = lig + 1 ActiveWindow.Zoom = k Cells(lig, 7) = ActiveWindow.ActivePane.PointsToScreenPixelsX(k) * ActiveWindow.Zoom / 100 Cells(lig, 8).FormulaR1C1 = "=SUM(RC[-1]-R[-1]C[-1])" Next ActiveWindow.Zoom = 100 Range("G1").Value = "PTTOPTX x Zoom" Range("H1").Value = "Ecart " Range("H2").Value = "" End Sub

---

Allons bon ...
Nous allons démontrer que le zoom ne commet aucune erreur. Je voulais éviter cet affront, mais trop, c'est trop.
Il suffit :
d'un userform (ici userform3) sur lequel on place un label label1
et ce code à cent sous :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

With UserForm3 .StartUpPosition = 0 With .Label1 .BackColor = vbRed .Left = 0 .Height = Range("A1").Height * ActiveWindow.Zoom / 100 .Width = Range("A1").Width * ActiveWindow.Zoom / 100 .Top = UserForm3.InsideHeight - UserForm3.Label1.Height End With UserForm3.Show 0 End With

---

voilà.
Choisir maintenant le zoom que l'on veut, puis lancer ce code. Faire maintenant déplacer le userform de sorte à comparer la hauteur du label et celle de A1. Déplacer à nouveau pour comparer maintenant les largeurs.
Voilà voilà : le zoom ne commet aucune erreur.
Bonne nuit

ca n'est pas une croyance c'est un fait en mode dpi 120

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Sub testzoom() With ActiveWindow .Zoom = 100 Debug.Print "zoom 100 " & .PointsToScreenPixelsX(0)   For i = 101 To 120 lig = i - 99 .Zoom = i Z = .Zoom / 100 Debug.Print "zoom " & i & "=" & .PointsToScreenPixelsX(0) Next ' End With End Sub

---

elle est pas belle la série la hein !!

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

zoom 100 46 zoom 101=49 zoom 102=49 zoom 103=49 zoom 104=49 zoom 105=49 zoom 106=49 zoom 107=49 zoom 108=49 zoom 109=49 zoom 110=49 zoom 111=49 zoom 112=52 zoom 113=52 zoom 114=52 zoom 115=52 zoom 116=52 zoom 117=52 zoom 118=52 zoom 119=52 zoom 120=52

---

maintenant reprends la valeur du zoom 100 soit 46
et multiplie le par 1.2 pour le zoom 120 ca fait combien hein !!?????
:mouarf:
et ne me dis pas que c'es pointstoscreenpixels le test avec setcursorpos démontré toute a l'heure prouve bien le contraire

et le encore une fois avec ton userform tu démontre ce que tu ne vois pas tu fais la même erreur d'interprétation

je sais plus comment faire pour que tu ouvre les yeux

le calcul de ton zoom oui il est bon ca: y a pas de soucis tu test tes height ca te donnera toujours bon

mais la réalité de l'affichage est différente démontré plus haut avec la cellule encadré en rouge

par contre pointstoscreenpixels trouve le bon point prouvé plus haut avec setcursorpos

alors qu'est ce qu'il se passe
en fait rien du tout
le fait que le zoom fausse l'affichage sur la grille forcement pointtoscreenpixel en terme de donnée numerique de la position d'une cellule donnera faux par rapport au calcul fait avec les même donnée en dur forcement puisque le zoom est incrémenté régulièrement mais la différence a l'affichage ne l'ai pas
mais la position de pointstoscreenpixels sera exacte
tu les veux en plus grosse les captures ???? en HD 4 k peut etre ?

allez un exemple encore plus flagrant
la ici on laisse tomber pointstoscreenpixels d'accords?

fait ce simple test ici tout est en point il n'y a pas de conversion a part le zoom
j'ai testé avec un zoom 130

Code:

---

1 2 3 4 5

Sub test_userform_scale() Z = ActiveWindow.Zoom / 100 With UserForm1: .Show 0: .Left = 0: .Top = 0: .Width = [A1:f5].Width * Z: .Height = [A1:f5].Height * Z: End With   End Sub

---

maintena que l'userform est a ffiché place le dans la range qui nous a servi pour ses dimensions
qu'est ce que tu vois ? tu vois pas
bon allez capture!!
Pièce jointe 291763
tu vois mieux ou pas ?

Commençons pas la plus énorme des énormités que tu as avancées, patricktoulon

Citation:

---

maintenant reprends la valeur du zoom 100 soit 46
et multiplie le par 1.2 pour le zoom 120 ca fait combien hein !!?????

---

dans l'équation x = a + b , une augmentation de n % de la valeur de b ne saurait en aucun cas se traduire par une augmentation de n % de la valeur de x
Il se trouve que, dans cette équation :
- x est une coordonnée relative par rapport à l'ECRAN
- a est est l'addition de la coordonnée correspondante (top ou left) de la fenêtre APPLICATION et de toute la zone de cette fenêtre ne subissant aucunb effet du zoom
- b est la seule coordonnée subissant l'effet du zoom
une modification en pourcentage de b ne saurait en aucun cas se traduire par une augmentation en même pourcentage de y

passons maintenant au reste :

Citation:

---

le calcul de ton zoom oui il est bon ca: y a pas de soucis tu test tes height ca te donnera toujours bon mais la réalité de l'affichage est différente

---

n'a aucun sens. La vocation du zoom n'est autre que celle de l'affichage d'un "miroir homothétique". Si les valeurs GRAPHIQUES ainsi AFFICHEES (et vérifiables et vérifiées) sont celles attendues, le zoom a parfaitement accompli sa tache. C'est quoi, ta "réalité de l'affichage" ????? Depuis quand y aurait-il une "réalité" d'un affichage différente de l'affichage ??? Traduis donc cela, pour voir !

Citation:

---

et ne me dis pas que c'es pointstoscreenpixels le test avec setcursorpos démontré toute a l'heure prouve bien le contraire

---

Il se trouve justement que c'est là que la bât blesse. Dans certaines circonstances, configurations et cas de figure, même le curseur est quelquefois mal placé ...
Une chose est d'ailleurs très nette à ce propos : Excel n'a plus rien à voir (et son zoom encore moins) dans la transposition de pixels en points de coordonnées relatives par rapport à l'ECRAN.

Venons-en maintenant à ta dernière partie (ton "test" et son code) qui prétendent :

Citation:

---

Allez un exemple encore plus flagrant
la ici on laisse tomber pointstoscreenpixels d'accords?

fait ce simple test ici tout est en point il n'y a pas de conversion a part le zoom
j'ai testé avec un zoom 130
Code : Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5


Sub test_userform_scale()
Z = ActiveWindow.Zoom / 100
With UserForm1: .Show 0: .Left = 0: .Top = 0: .Width = [A1:f5].Width * Z: .Height = [A1:f5].Height * Z: End With

End Sub
etc ....

---

Je ne teste même pas. Nul besoin de tester quoi que ce soit pour savoir qu'un tel code ne peut que placer le userform tout en haut et tout à gauche de L'ECRAN et en aucun cas sur la grille comme le "montre" ta capture d'écran ! C'est encore une autre plaisanterie ?
Et que viennent en outre ficher là des dimensions de l'userform ? Qu'auraient-elles à voir avec le PLACEMENT de l'userform ? Rien !
Et en plus (et c'est le pompon ...) confondre le zoom (miroir homothétique qui ne touche pas aux propriétés de ce qui est "zoomé") avec une intervention réelle sur les dites propriétés est la démonstration de ce que j'avais finalement bien choisi (dans un message plus haut) le nom que j'avais donné à une certaine variable.

Pour résumer : on touche là le fond du fond et j'ai assez perdu de temps comme cela.

EDIT : ah oui "tu déplaces" ensuite pour comparer.
Je te signale que je viens de le faire et que je n'ai pas de problème : la bordure droite de l'userform coïncide parfaitement avec celle de la colonne F. Et ce : quel que soit le facteur de zoom.
Ceci étant dit : il est maladroit d'utiliser un userform (ses bordures, style etc ... pourraient fausser, d'une version à l'autre). Il est bien plus sage d'utiliser un contrôle le p^lus plat possible et sans bordure placé sur un userform (ce que j'ai fait plus faut avec un label sans bordures).

tu refuse encore de croire malgré toute les démo soit disant avec ton "miroir "que pointtoscreenpixels donne la vrai position démo avec le cursor a l'appui qui chez moi avec 2007 et 2010 ne se trompe jamais de zoom 50 a zoom 400
parti de la que veux tu que je te dise
j'espère que ton groupe de gens sérieux vont pouvoir te le démontrer
j'ai d'ailleurs fait un test rapide hier soir

au lieu du zoom j'ai appliqué le coefficient zoom au height et width des cellules de 50 a 400 dans une boucle temporisées et cela en restant en zoom 100

et devine quoi? pointstoscreenpixel correspond parfaitement avec le height et width par coefficient ppx(1.3333... ou 1.666... selon dpi)alors qu'avec le zoom ca n'était pas le cas

autrement dit en remplaçant le zoom par un dimensionnement correspondant au zoom les unité en point et en pixels correspondent visuellement et mathématiquement

et le curseur est bien en placé et le userform aussi

reste les -5 a +4.4 pour les userforms qui sont complètement indépendants de Excel car il sont dus au paramètres d'affichage gérer par le shell et même la j'ai compris pourquoi

il a fallu que je fasse un tour dans ma classe "formica" que l'on trouve dans les contributions et jouer avec les apis pour comprendre cet écart tout du moins visualiser pourquoi

mais bon je suis impatient de connaitre les conclusions de ton groupe

Citation:

---

au lieu du zoom j'ai appliqué le coefficient zoom au height et width des cellules de 50 a 400 dans une boucle temporisées et cela en restant en zoom 100

et devine quoi? pointstoscreenpixel correspond parfaitement avec le height et width par coefficient ppx(1.3333... ou 1.666... selon dpi)alors qu'avec le zoom ca n'était pas le cas

autrement dit en remplaçant le zoom par un dimensionnement correspondant au zoom les unité en point et en pixels correspondent visuellement et mathématiquement

et le curseur est bien en placé et le userform aussi

---

Ah ! ...
"et devine quoi" (puisque tu aimes l'expression) :

Citation:

---

dans l'équation x = a + b , une augmentation de n % de la valeur de b ne saurait en aucun cas se traduire par une augmentation de n % de la valeur de x
Il se trouve que, dans cette équation :
- x est une coordonnée relative par rapport à l'ECRAN
- a est est l'addition de la coordonnée correspondante (top ou left) de la fenêtre APPLICATION et de toute la zone de cette fenêtre ne subissant aucunb effet du zoom
- b est la seule coordonnée subissant l'effet du zoom
une modification en pourcentage de b ne saurait en aucun cas se traduire par une augmentation en même pourcentage de y

---

en zoom 100%, tu n'as aucune modification de b dans l'équation, pardi ! Elle est bien bonne.
En autre facteur de zoom, la méthode pointstoscreenpixels conduit à une erreur très probablement simplement due à son incapacité (mauvais calculs ou non précision suffisante de parties "fixes") à déterminer la valeur exacte de b.

je viens de tester dans un classeur vierge
et c'est même pas le ZOOM (je dis ca entre guillemet hein) QUI EST EN CAUSE MAIS CAREMENT TON espèce de MIROIR homoserectus a la mord moi le.... ou je sais pas trop

il doit y avoir une raison pourquoi le grossissement écrase l'affichage par le zoom ou le redimensionnement c'est la qu'il faut chercher j'en découvre de jour en jour
regarde cette macro je zoom pas mais fait la même chose en redimensionnant une cellule pourtant si je fait un msgbox cellule.width ou height ca correspond bien au calcul
il y a bien écrasement horizontal malgré une itération régulière x coup sur y dont je n'ai trouvé aucune raison

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Declare Sub Sleep Lib "kernel32" ( _ ByVal dwMilliseconds As Long) Sub testsanszoom() With ActiveSheet .Columns("a:z").ColumnWidth = 10 .Cells.RowHeight = 7 End With For i = 100 To 200 With ActiveSheet .Range("b3").ColumnWidth = 10 * (i / 100) .Range("b3").RowHeight = 7 * (i / 100) End With Sleep 100 Next End Sub

---

mais c'est bien le grossissement le fond du problème

Citation:

---

et c'est même pas le ZOOM (je dis ca entre guillemet hein) QUI EST EN CAUSE MAIS CAREMENT TON espèce de MIROIR homoserectus a la mord moi le.... ou je sais pas trop

---

ah tiens ! ce qui était une conviction "démontrée" avec une énorme "assurance" , n'en est plus une et on cherche un autre "coupable".
Et que veut dire ""je dis ca entre guillemet hein" ?
Et ta prochaine "assurance" accompagnée d'une "démonstration" sera quoi ?
Tu finiras bien par comprendre enfin ce qui t'a été expliqué de différentes manières à différentes reprises.
Ce n'est ni le zoom, ni son affichage, le "coupable". C'est l'exploitation (des calculs sur la partie fixe et celle soumise au zoom) que fait erronément la méthode pointstoscreenpixels. Le zoom, son affichage, ne sont que l'occasion donnée à la méthode de se "planter" dans ses calculs. :D

j'ai des convictions mais je ne suis pas fermé
en tout cas que se soit le zoom ou autre chose le problème vient bien de la
c'est le grossissement qui n'est pas régulier

en tout cas ma conviction reste la même pointstoscreenpixels fonctionne parfaitement bien

j'ai beau le tordre dans tout les sens il reste correcte a 100%

alors a moins que tu connaisse la formule qui pali a cette déformation je pense que l'on pourra rien faire de plus que palier avec mon switch version ou tout autre méthode qui consisterait a diminuer ou augmenter de quelques points

affaire a suivre je continu de chercher
cette déformation me fait penser a nos cher écrans d'antan qui était en 4/3 et que maintenant ils sont quasi tous en 16/9 ou 16/10

si cela devrait être une piste je doute que l'on trouve les solutions sans aide externe(api ou autre) de excel

dans ce cas la le chalenge est bouclé pour moi

bonjour,
vite fait en passant,...
j'ai survolé le post de Patrick

c'est bien ce que j'avais noté : en fonction du zoom, la taille de la police par défaut est modifiée , ce qui entraîne un "calibrage" des ligne et cellule

@+JP

Citation:

---

que l'on pourra rien faire de plus que palier avec mon switch version ou tout autre méthode qui consisterait a diminuer ou augmenter de quelques points

---

toute la différence est là, patricktoulonj
- toi, tu cherches à "palier"
- moi (et d'autres avec moi), je cherche à dénoncer et ne cherche pas à me "substituer" à coups de rustines aussi hasardeuses qu'antinomiques du point de vue informatique.
Nous cherchons donc à démontrer un bug et à forcer Microsoft soit à le corriger, soit à cesser de présenter sa méthode Pointstoscrennpixels parmi celles fonctionnelles.
Et au passage :
- ton approche :
1) nécessiterait autant de "rustines" (au demeurant aléatoires) que de cas (déjà connus et futurs et non encore connus) de versions, etc ... . Tu vas où, comme cela ????? Tu peux nous l'expliquer ???
2) passerait définitivement aux oubliettes (déjà dit et redit) si correction du bug ou si suppression de la méthode.

Tu la comprends, cette différence énorme ? OUI ? NON ? :cfou:

Bon, Patricktoulon :
Tu sais quoi ? La bande de "rigolos" que nous sommes dans un cercle particulier (tu sais ... ceux à l'égard desquels tu as exprimé de l'ironie à plusieurs reprises) venons de décider (bien que nous n'aimions pas du tout ce genre de démarche qui tend à faire face en dépit de la présence d'un bug évident) de tenter de faire en sorte que le userform se place malgré tout où il faut, mais en aucun cas à coups de "rustines", "rafistolages", etc... en tous genres, hein ...
Nous allons le faire sur la base de ce que nos tests (tu sais ... des calculs de "rigolos") tendent (sans encore le prouver totalement) à mettre en exergue en ce qui concerne un élément essentiel utilisé par la méthode pointstoscreenpixelsX/Y.
Tout sera tenté par la conjugaison :
- de l'utilisation différente de cet élément
- de l'application (tu sais ... l'équation x = a + b qui te fait tant rigoler) de la différenciation à faire entre la partie "fixe" et celle seule soumise au zoom.
Et surtout : SANS des cataplasmes correctifs divers, pour le moins arbitraires et totalement antinomiques en matière d' "unviversalité"
Ce ne sera pour nous qu'un intermède sans aucun intérêt, même si nous réussissons ainsi à placer parfaitement le Userform.
Nous nous y mettrons demain matin et devrions avoir fini nos essais au plus tard demain soir.
Jusque là, s'il te plait : patiente et ne viens pas noyer un peu plus encore le poisson.
A demain.

Citation:

---

bonjour,
vite fait en passant,...
j'ai survolé le post de Patrick

c'est bien ce que j'avais noté : en fonction du zoom, la taille de la police par défaut est modifiée , ce qui entraîne un "calibrage" des ligne et cellule

@+JP

---

non jp!! c'est la ou je rejoint unparia ,en fait le zoom c'est comme l'effet d'une loupe sauf que le height et width n'est pas respecté proportionnellement a tout les niveau de zoom
et la attention je ne parle que VISUELLEMENT car dans l'absolu les dimensions sont bonnes en lecture

par contre pointtoscreenpixels lui déformé ou pas trouve la bonne coordonnée qui correspond a la position visuelle

alors en effet
si je fait cellule .height*z +le active window.left et compagnie *(1.33333333(coefficient pixel to point) je n'aurais pas la même qu'avec directement pointtoscreenpixel reduit en point

c'est tout a fait normal si je puis m'exprimer ainsi

pour faire court depuis le début de notre périple c'est simplement un défaut d'affichage que pointtoscreenpixels ne subit pas puisqu'il est sensé nous donner un point de L'ECRAN
C'EST UN TRUC TRES CON DEPUIS LE DEBUT


unparia
je suis d'accords avec toi sur le plan de la rectification plus on va avancer dans les versions plus le switch va être long
c'est pour ce la que suis en train de chercher ailleurs ,c'est ce qui m'attriste car on risque de devoir utiliser des object externes (api et/ou autre)
ce qui rend ce chalenge obsolète car le but était justement de s'en passer
tout code même donnant un résultat parfait partout dans toute les conditions en utilisant des object externes serait pour moi d'aucun intérêt du a ca justement

je suis impatient a demain

edit
@ JP
si tu cherche bien sur le net la conversion font pixel to font en point que l'on utilise en javascript tu verra se dessiner une serie ressemblant étrangement( pour ne pas dire identique)a la serie d'inégalité que l'on observe avec le zoom excel
c'est un soucis récurent dans beaucoup de language informatique
en effet la conversion picel point n'est pas progressive régulièrement

bonjour à tous,

@ Patrick

Citation:

---

edit
@ JP
si tu cherche bien sur le net la conversion font pixel to font en point que l'on utilise en javascript tu verra se dessiner une serie ressemblant étrangement( pour ne pas dire identique)a la serie d'inégalité que l'on observe avec le zoom excel
c'est un soucis récurent dans beaucoup de language informatique
en effet la conversion picel point n'est pas progressive régulièrement

---

dans cette approche "du relatif (au cadre de excel)" , effectivement il faut intégrer le calibrage des barres x/y
(trouver l'info sur la police, le rapport ,...) mais tout ceci est pour 2010, avec 2016 d'autres éléments graphiques sont aussi à prendre en compte.!!!

l'approche relative:
atteindre le coin haut gauche de l'espace de travail
ajouter plage.large ou plage.haut

pour résumer en image :
le form a la hauteur de tous les éléments jusqu’à l'espace de travail

avec police 11
Pièce jointe 292303
Pièce jointe 292309

avec police de 8 à 10
Pièce jointe 292317
Pièce jointe 292322

@+JP

Je vais dans ce qui suit utiliser le pronom personnel "nous" et non "je", car

tout ce qui va y être exposé est le fruit du travail de 11 membres (dont moi-même) d'un cercle et non du seul mien.
Les 10 autres membres concernés (tout au moins ceux qui comprennent suffisamment le français car différentes nationalités) sont par ailleurs à même d'accéder au présent forum et de lire le présent message.

Pour que le code et ce qui suit soit compréhensible, il est nécessaire de donner certaines explications liminaires --->>

Il nous est apparu, mais sans trouver le moyen de le prouver de manière parfaitement irréfutable (via des observations sur plusieurs tests) que la méthode pointstoscreenpixelsX/Y (et plus particulièrement pointstoscreenpixelsX) ne transformait pas directement des unités de points en coordonnées relatives par rapport à l'écran exprimées en pixels. Il nous est impossible de vérifier le mécanisme de transposition sans avoir accès au code qui régit la méthode, mais tout (tests et calculs) nous a donné à penser :
- que le paramètre (exprimé en points) des unités à transposer est d'abord lui-même transposé en unités de pixels avant d'être traité par la suite du code
- que c'est ensuite sur ces unités transposées en pixels que le code de la méthode "travaille" pour en déduire la coordonnée correspondante, exprimée en pixels par rapport à l'ECRAN
- que de manière assez aléatoire et sans que l'on ne puisse (sans accès au code) déterminer pour quelles raisons, cette première transposition de points en pixels est quelquefois court-circuitée. Que cela se produit plus fréquemment en ce qui concerne pointstoscreenpixelsX et moins fréquemment en ce qui concerne pointstoscreenpixelsY. Que ce "bug" intervient également plus fréquemment avec certaines versions et moins avec d'autres (sans que nous ayons eu la moindre chance de savoir pourquoi).
- qu'il devenait dès lors très aléatoire, voire carrément risqué, d'appliquer directement la méthode pointstoscreenpixelsX/y à des coordonnées de cellules, exprimées en points du fait de leur propriété.
- qu'il était du même fait impossible de déterminer le dpi en vigueur par comparaison d'unités qui n'étaient ainsi plus toujours assurément comparables.

Qu'avons-nous alors tenté ? ceci --->>
Nous avons considéré que la détermination de la transposition d'un nombre nul d'unités échappait à l'incidence d'un éventuel court-cicuitage puisque 0 points sont toujours également, par définition, 0 pixels.
Or, qu'est le point 0,0 de la fenêtre active sinon précisément celui de l'angle supérieur gauche de la grille ?
en passant donc systématiquement la valeur 0 (0 points = 0 pixels) qu'obtient-on donc alors tranquillement ? --->> la coordonnée correspondante par rapport à l'écran, exprimée en pixels, de la coordonnée 0 de la grille.
En transposant en points cette coordonnée, nous obtenons sa valeur en point par rapport à l'angle supérieur gauche de l'ECRAN. Et cette coordonnée n'est rien d'autre, précisément que dans l'équation x = a + b
Nous restait dès lors à déterminer la valeur en POINTS de la variable b (la seule soumise à l'effet du zoom) -->> ben ... nous la connaissons -->> ce n'est que la coordonnée (x ou y) de l'angle supérieur gauche de la cellule à traiter !
Quelle chance -->> nous reste alors plus qu'à appliquer le coefficient du zoom à ce paramètre b de notre équation --->>

Et voilà donc le code que nous en avons conclu --->>

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Private Sub Worksheet_SelectionChange(ByVal Target As Range) Dim pixelstopoints As Double, objWSH As Object Set objWSH = CreateObject("WScript.Shell") pixelstopoints = objWSH.RegRead("HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics\AppliedDPI") / 72 Z = ActiveWindow.Zoom / 100 With ActiveWindow.ActivePane UserForm3.StartUpPosition = 0 UserForm3.Top = (.PointsToScreenPixelsY(0) / pixelstopoints) + (Target.Top * Z) UserForm3.Left = .PointsToScreenPixelsX(0) / pixelstopoints + (Target.Left * Z) UserForm3.Show 0 End With Set objWSH = Nothing End Sub

---

Ce code a pour l'instant été testé sans faille avec différentes versions, mais cela ne garantit aucunement que nous ne sommes pas passés "à côté" d'une faille de test.
Nous ne pouvons donc compter que sur vos propres essais avec différentes versions et configurations pour confirmer ou infirmer la justesse de ce code.
Voilà.

PS : j'ajouterais ceci : en ce qui le concerne, notre cercle ne tire de cette étude et des tests associés qu'un seul bénéfice inattendu et collatéral : nous sommes maintenant capables de déterminer avec précision la hauteur en points de la barre horizontale des titres (Noms des colonnes) de la grille ainsi que la largeur en points de la barre verticale des titres (N°s des lignes) de la grille.
Mais il s'agit là d'une autre chose, totalement collatérale.

PS 2 : j'ai inclus dans l'évènement les lignes de code 3 et 4 (celles qui déterminent le dpi en vigueur)
Je ne l'ai fait que pour faciliter la compréhension.
Il est clair qu'il sera moins coûteux d'exécuter ces lignes, une fois pour toutes, dans l'évènement d'ouverture du classeur.

PS3 : je le dis et le répète : notre cercle ne considère en aucun cas comme acceptable une solution à un bug et cela ne remet donc nullement en cause l'injonction que nous allons faire à Microsoft ;)

re
@JP
donne moi tes macros les captures ne me parlent pas plus que ca