Version imprimable
Salut Marc,
Pour ne pas trop entrer dans le détail, PointsToScreenPixels a ses défauts lorsque certaines hauteurs et/ou largeurs de cellules tombent dans des arrondis Excelliens posant soucis. Ça n'est jamais le cas, par exemple, sur une feuille "neuve"...
De plus, le positionnement du curseur peut également s'avérer délicat selon certains facteurs de zoom, dependants du DPI.
Pas si évident ni si simple que cela n'apparaît au premier abord.
bonsoir marc
je pense avoir suffisament crié haut et fort que perso je n'ai aucun problème avec pointstoscreenpixels
même si il est vrai que dans n'importe quel sens l'arrondi génère un calcul faux mais trop insignifiant visuellement
alors oui c'est vrai c'est indéniable que les thème aero pour W7 et "roamed" et pour W 10 génère un décalages facilement remédiable on en a vue quelque une (chacun sa bible)
ensuite j'ai démontré largement que le dpi issu de Windows(par les api ou le registre ) n'était pas bon( dans le sens ou il n'est pas respecter par l'affichage excel a l''écran ) dans cet exercice au vue de la déformation apparemment aléatoire des largeur et h
auteurs de ligne colonnes (aléatoire ..pas vraiment)je me suis rendu compte que quand on, tombe sur des nombre premiers il y a des chose bizarre
et c'est en ne cherchant plus que je suis tomber sur un site (forum) qui traitait ce sujet
alors dans ce (riquequandquoimaisouetdoncornicar)on trouvera divers solutions toutes intéressante et donnent un visuel relativement acceptable
mais aucune avec un résultat exact car trop de différence entre version et même config PC
pour ma part le chalenge était de ne pas se servir d'api et autre Object externe donc en ce qui me concerne le challenge est rempli chez moi pour W7 et W10
je pense avoir suffisamment passer de temps sur ce sujet et observé pour en parler
après chacun sa bible
en tout cas chez moi PAS d'api thème "aero" /"roamed" ou pas
bien le bonsoir ;)
je donne un dernier indice et pas plus
" ce que donne les api le registre aussi"
demerdez vous avec ca
Bonsoir Patrick,
Ce que donne l'api, le registre le donne aussi.
J'aimerais bien savoir comment le registre te donne l'écart entre les deux modes aero ou pas.
Parce que là, effectivement, on pourrait (conditionnel) se diriger vers une solution complète sans api.
Il reste néanmoins des obstacles, que tu es encore loin d'imaginer, pour l'obtention d'une solution universelle ET rigoureusement exacte.
Par ailleurs, je ne sais pas, à ce jour, si une telle solution est réalisable, tellement il y a de paramètres à prendre en compte, et notamment les approximations de Monsieur Excel.
Bonsoir à toutes et à tous.
Ps : je reste ouvert à la discussion, mais sans partir dans tous les sens comme l'ont démontrées ces 40 ou 50 dernières pages.
Juste un mot (et je ne traînerai pas plus dans cette discussion) :
1) La solution "universelle", je la tiens déjà personnellement, mais :
pas pour la totalité des facteurs de zoom dans la tranche 25 - 400 inclus , mais pour une très grande quantité **1** en 96 DPI et une moins grande quantité **2** en 120 DPI
Franck (que je salue) et moi en sommes maintenant à chercher à "étendre" à la totalité absolue des facteurs de zoom. Je ne sais pas si nous y parviendrons, mais nous avons déjà trouvé un palliatif qui consiste à modifier automatiquement au besoin légèrement (plus légèrement en 96 dpi qu'en 120 dpi) le facteur de zoom choisi par l'utilisateur.
2) ce qui est dit en 1) concerne la détermination très précise des coordonnées/écran de l'angle supérieur gauche d'une cellule.
3) quant à l'aspect placement du userform aux coordonnées précises concernées par le 2), je sais déjà faire, aero ou non. Et cet aspect-là est TRES secondaire.
Je veux souligner ici que le travail en solo est pour l'instant plus fructueux (et de très loin) que la "dispersion" qui m'a fait fuir la présente discussion
J'arrête là mon retour très "furtif" dans cette discussion.
**1** tous les facteurs "normaux" + environ 70 "personnalisés" additionnels
**2** tous les facteurs "normaux" + une dizaine de "personnalisés" additionnels
la petite modif pour le dpi en fonction du plus grand nombre de zoom tu l'obtient avec ppx par la formule par ptscpix sur cellule voila pour la correction hors aero et compagnie
Patrick,
désolé, mais je n'ai rien compris à ton message. ..
re
Bonjour pijaku
quel message ?
Bonjour,
Celui d'1h14.
Salut Franck
Comment cela, tu n'as rien compris à son message ?
Je vais t'expliquer : tu mets trois bonbons dans le pot de miel. Tu fermes le tiroir de la commode d'entrée et souffles sur la première mouche qui passe ;)
Plus sérieusement : s'il s'agit d'obtenir un résultat très précis (des coordonnées/écran de l'angle supérieur gauche d'une cellule) sur la totalité des zooms de 25 à 200 inclus, d'accepter un infime/quasi imperceptible décalage sur la totalité des zooms de 201 à 300 inclus et d'accepter un décalage aléatoire d'au maximum 2 pixels sur la totalité des zooms de 301 à 400 inclus --->> non seulement je sais déjà faire, mais de surcroît sans le moindre calcul basé sur le zoom, et sans même me préoccuper de la configuration en DPI (sans même la déterminer, que ce soit par api ou par lecture dans la base de registre).
Et encore : lorsque décalage (de 201 à 300 ou de 301 à 400) : il n'intervient que très rarement :lol:
Mais je n'aime pas certaines contradictions : dire et exiger que l'on obtienne la perfection et finir par dire après 50 pages que l'on se fiche des décalages infimes ("le renard et les raisins" ? ... ou le chat qui, ayant perdu sa baballe, prétend, en s'éloignant avec dignité et désintéressement, qu'il n'avait jamais joué avec ?)
Patrick, mon exemple n'est pas pour les API (car effectivement via le registre …)
mais juste pour la manière d'utiliser les fonctions PointsToScreenPixels.
Et tu pourrais partager le lien traitant ce sujet …
Jacques, Franck, bon courage pour vos recherches menant à l'universalité
en espérant lire votre future contribution à la rentrée. :lun:
Marc,
Selon moi, l'universalité ne pourra être obtenue qu'à la condition que Microsoft accepte de modifier sa fonction PointsToScreenPixels, ou nous en donne une autre qui soit réellement fonctionnelle(à base peut être de GetCursorPos...).
Parce que oui, peut être, nous (Jacques et moi) parviendrons à trouver l'emplâtre sur cette jambe de bois, mais quid de windows2024 avec Excel 17???
Et encore, personne n'a songé aux tests sur office365.........
Jacques,
Bonjour,
N'hésite pas à m'envoyer tous tes codes, toutes tes avancées et toutes tes idées, même les plus farfelues ou aventureuses.
Bises à toutes et tous, je retourne à mon anniversaire, 44 ans today!!!
Hâte de vous lire quand j'aurais les idées claires. ....
Bonjour
comme je l'ai dis plus haut
il faut s'occuper uniquement du pointstoscrennpoixelsx/y(0)
pourquoi ?
et bien tout simplement parce que contrairement a ce que tu crois il n'est pas faux il te donne la vrai position écran par rapport a Excel et non a l'écran tout court
avec ceci: on a un séreux problème d'arrondi dans les calculs et jusqu'à présent il y en a 2 ou trois selon l'emploi de pointstoscreenpixelce qui nous fait 3 arrondissement des sommes qui font la totalité
donc comme l unité pixel trouvé ne correspond pas celle de Windows forcement les fenêtres qui son gérées elles par le shell ne peuvent pas correspondre
pour enrayé ce problème j'utilise l'obtention de PPX par la formule pointstoscreenpixelsX/Y(cellule concernée)-le (0)/par la cellule concernée /coeff zoom
quand vous aurez accepté cela vous verrez que l'écart est beaucoup moins grand
vous rajouterez a cela pour les utilisateur de W10 une erreur monumentale a savoir le blind ou carrément un oubli de la place que prend aero dans W7 qui est resté dans W10 et cela pour rien
puisqu'on est revenu pratiquement au skin de XP sans les coins arrondi du moins (moins grand l'arrondi)
ne me demandez pas pourquoi ils l'ont laissé
conclusion
faire le moins de calcul possible a fin de réduire les arrondis lors de la conversion
juste sur le ptscpix(0) l'erreur d'arrondi est minime et ajouter cellule.left et top pour le reste
ainsi on a pas de conversion donc pas d'arrondissement et en plus en employant le left ou top on a la vrai position étonnamment malgré la déformation ,je ne peut pas vous dire pourquoi
il y a peut etre une divergence entre l'écriture et lecture de la propriété je l'ai déjà constaté avec un msgbox un left de x.15 est arrondi a x ce qui est assez conséquent quand même vous en conviendrez surtout que la on parle en unité point hein je précise au cas ou
bref on a tout il faut simplement comprendre comment s'en servir
pour ma part
ppx dpi Windows est proscrit dans cet exercice
ce qui déjà réduit considérablement l'erreur de position (j'utilise le height/width) car le left et top me génèrerait une erreur si l'active celle est A1 forcement (erreur division by zero!!!)Code:
2
ensuite pour aero seul le thickframe est a gérer sur W7 et pour W10 compenser le blind des cotés en trop qui n'a rien a foutre la
voila bon anniv!!!
Marc,
Merci beaucoup!
Patrick,
Merci pour tes bons voeux.
En ce qui concerne ton texte et le code qui va avec je verrais demain hein?
et Pour info je peut vous montrer la preuve irréfutable que pointstoscreenpixels y est pour rien dans le problème si ce n'est un arrondi minime de l'ordre d'un demie pixel ce qui est insignifiant au visuel
comme je le disais précédemment on a tout il suffit de comprendre comment s'en servir
resultatCode:
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
alors dite moi encore que c'est pointstoscreenpixels:mouarf:Citation:
zoom = 100
largeur non soumise au zoomet non soumise a ptscpix 62,4
largeur soumise au zoom 62,4
largeur soumise au zoom by pix 62,4
et maintenant avec pointstopixel windows soit 1,66666666666667
largeur soumise a ptscpix et!!!!! pointtopixel window 61,8
zoom = 200
largeur non soumise au zoomet non soumise a ptscpix 62,4
largeur soumise au zoom 62,4
largeur soumise au zoom by pix 62,4
et maintenant avec pointstopixel windows soit 1,66666666666667
largeur soumise a ptscpix et!!!!! pointtopixel window 61,8
--------------------------
je tiens a préciser tout de même que le 62.4 en ce qui concerne ce que l'on voit a l'écran sera faux!!! selon les zoom , mais pointstoscreenpixels n'en est d'aucune façon responsable, c'est ce qui y est injecté qui en est la cause c'est bien la deformation zoom qui en ai responsable
vous voulez voir le meme teste avec un valeur en dur a la quelle on applique le zoom vous verrez la différence
et vous pouvez tester avec n'importe quelle cellules je le dis au cas ou hein
c'est bon tout le monde a compris ;)
bien le bonjour chez vous :mouarf:
A Franck seul :
1) Très joyeux anniversaire
2)Je viens de fignoler un code que j'avais commencé il y a quinze jours (et auquel je me réfère un peu plus haut) :Citation:
Jacques,
Bonjour,
N'hésite pas à m'envoyer tous tes codes, toutes tes avancées et toutes tes idées, même les plus farfelues ou aventureuses.
- sans faire appel à la moindre fonction de l'Api de Windows pour déterminer le DPI
- sans faire appel ni à shell ni à quoi que ce soit (même pas lire le registre) pour déterminer le DPI
- sans me préoccuper du facteur de zoom
J'ai maintenant considérablement réduit les rares décalages minuscules éventuels (je crois même qu'ils ne sont même plus là).
Il fonctionne chez moi (sans aero) :
- pour tous les facteurs de zoom compris entre 10 et 400 inclus en dpi 96 (je dis biens tous, y compris par exemple 13, 122, 204, ....)
- pour tous les facteurs de zoom compris entre 10 et 399 inclus en dpi 120 (je dis biens tous, y compris par exemple 13, 122, 204, ....). Un très infime décalage est perceptible à 400
Il est très difficile de constater la justesse en dessous d'un facteur de zoom 25, mais la forme même du curseur suffit à comprendre qu'il est bien placé, même dans ce cas.
Ce qu'utilise ce code est tel que je serais surpris que la présence de aero produise d'autres résultats. Mais c'est à tester par acquit de conscience ;)
Je fais le ménage dans ce bout de code (très court, tu verras) après dîner et te le communique par MP pour tests avec et sans aero et en 96 et 120 dpi.
Amitiés
Bonjour à tous
J'ai beaucoup de respect pour tout le monde,
mais Jacques ton derniers messages je n'en vois pas la nécessité sur le forum si c'est pour dire au final que tu l'envois par mp
Ridicule un peu qu'en même
Bonjour Nicolas
Pas vraiment et totalement "ridicule".
Il est là très délibérément pour tenter de stopper net des idées de mécanismes causes d'inexactitude et d'autres suppositions encore. ;)
Le code sera montré (mais pas dans cette discussion) après les tests de Franck, s'ils confirment la justesse.
EDIT : pour que ce soit plus clair : je veux simplement éviter que l'exposé de certaines "considérations" ne conduise d'autres à se lancer dans certaines directions (toutes aléatoires).
Mon message est de nature à les inciter à attendre un peu ...
re
pour justement concevoir un code qui passerait outre AERO il faut avoir aero
tu code avec Xp j'ai testé personnellement chez moi Xp SP3 avec 2007 et pointstoscreenpixels fonctionne sans autre mesure de redressage comme avec W7 en mode basic ou window classic d'ailleurs
et même avec le ppx window la marge est tellement minime hors AERO ,de 100 a 400 qu'il n'est même pas nécessaire de redresser ( un cheveux)
parti de la ,comment pourrais tu arriver a concevoir un code si chez toi avec XP tu redresse et moi avec Xp SP3 je redresse pas
bonjour a Nicolas au fait
tu suppute trop jacques , perso je préfère avoir un retour négatif même si des fois il y manque la manière plutôt que supputer
je trouve je partage je prends un gadin ou c'est bon mais j'avance
en ce qui me concerne utiliser le DPI WINDOW n'est qu'une erreur de jugement surtout que je l'ai démontrer mainte fois pas plus tard que toute a l'heure
alors attendre non ! car je sais que ca ne fonctionnera pas chez moi
ou alors ton truc va être une vrai usine a gaz
ma formule fonctionne tres bien
la seule chose que je n'ai pas du moins que je n'arrive pas a coder dans un code intelligible et qui me plombe pas la mémoire c'est le choix W7 /W10 tout le reste fonctionne sans api
Nicolas je t'enverrais des test moi aussi par MP :ptdr: