re
non!!!! le dpi modifié modifie tout ce qui est a l'écran
les icones ,les fenêtres etc...
le zoom Excel ne modifie que la grille Excel ca n'est pas la même chose
Version imprimable
re
non!!!! le dpi modifié modifie tout ce qui est a l'écran
les icones ,les fenêtres etc...
le zoom Excel ne modifie que la grille Excel ca n'est pas la même chose
En même temps tu ne te sers pas du Zoom excel dans ta fonction donc je me demande pourquoi j'ai posé cette question...
Donc, par la suite tu récupères la position en pixel de D3 avec ces lignes :
Et ensuite tu le divises par ton coefficient, mais pourquoi ? ^^Code:
2
ben c'est evident je me sert du coefficient pour et la c'est évident pour adapter a ce que l'on voit a l'ecran
encore une fois je dis bien ce que l'on voit a l'ecran
après activepane.pointstoscreenpixelsx([d3].left) nous donne le left en pixel de ce que l'on voit a l'ecran +ajouter l'operation d'ajustement selon version
ces ajustement n'ont rien a voir avec Excel en fait
la il s'agit du shell de l'api user32 qui gere l'affichage des fenêtres
en effet on constate que depuis Windows 8 les fenêtres ont une épaisseur de cadre différentes de W7
manque de pot il semblerait que ces ajustements n'ai pas été corrigé dans pointstoscreenpixels c'est pour cela que je le fait avec le switch
z en fait ne me sert qu'a ramener la dimension au niveau 100% zoom excel pour calculer le coefficient 1.333.... ou 1.6666.....pour l' affichage
ca parait compliqué mais pour une fois je suis d'accords avec unparia dans ses démonstrations graphique de ce qu'est la grille Excel et ce que tu vois a ton écran
ce qu'il d'ailleurs pense que je n'ai pas compris
pour ta démo capture t'est pas bon il faut donc ajuster ta config dans le switch seule les version w7 2007 et w10 office 14 et office 16 sont faites les autres je n'ai pas examiner les retours je suis sur un autre projet en ce moment
Ok merci pour le détails. :)
Pièce jointe 291576Code:
2
normalement débloque le msgbox pour connaitre ton switch
bon ben selon ta capture on est bon
amen!!
ton switch c'est quoi???????
edit je soupconne ton switch c'est bien celui la
""6,01-14","
ce qui corespont W7 et office 2010 c'est bien ca
J'ai rajouté le 6,01-14 dans le switch, avec un correctif de 4 pour le top et le left.
C'est sa. :)
oui chez moi aussi W7 et off 2010 c'est 4 j'attendais d'avoir d'autre retours pour confirmer
merci pour les retours Oudouner
là c'est constructif :plusser:
Aussi constructif que ton message #591 ? dont le "bruit" (clairon, tambour, cris de tarzan, etc ...) contraste avec l'énorme silence qui suit les remarques qu'il appelait quant à son absurdité ?Citation:
là c'est constructif
Lorsque l'on veut être un peu crédible, patricktoulon, on prend au moins le soin de reconnaître de telles âneries, ne serait-ce que par honnêteté à l'égard de ceux que l'on a conviés à tester "ABSOLUMENT" ce qui est tout sauf un test de fonctionnement du zoom ...
Je te laisse face à ... toi-même ...;)
Bonjour à tous,
J'ai fais un test ce matin, qui reprend le test de Jacques sur les écarts pxtopx et ça confirme bien qu'il y a un problème de ce côté là comme cela avait été montré , et un autre avec le zomm et les écarts sont régulier, pas de problème apparemment sur ce dernier, je vais essayer de faire combiner les deux au plus simple, mon niveau quoi et posterai ce soir. Suis pas à la maison.
la bonne blagueCitation:
tester "ABSOLUMENT" ce qui est tout sauf un test de fonctionnement du zoom ...
bref tout ce que tu pourra dire ne m'intéresse plus en attendant j'ai une solution qui fonctionne partout ou je!!! et fait testé par d'autre
toi t'a quoi rien du tout
a pardon si!!! un groupe de gens sérieux qui bossent dessus
je me langui de voir le résultat comme bon nombre de tes prétentions que l'on a jamais vu
on est pas d'accords voila tout point barre
stop et fin de l'échange en ce qui nous concerne
et arrête de m'insulter tu es limite le cancre tu sais ce qu'il te dis .......
je le répète stop et fin en ce qui te concerne
Désolé, mais je ne t'appartiens pas et je réagirai donc sur ce forum à chaque ânerie, chaque absurdité, que tu en sois ou non l'auteur.Citation:
je le répète stop et fin en ce qui te concerne
Ni moi, ni ce forum ne t'appartiennent. Comprends-le. ;)
Pour tous les autres visiteurs (et afin qu'il ne se laissent pas berner) :
J'ai rajouté au code du "test" proposé par patricktoulon une colonne ("hauteur de A1)
--->>
On voit bien que A1 ne voit en aucun cas sa hauteur modifiée du fait du zoom.Code:
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
ce qui fait que ce "test" n'est en aucune manière différent de ce que serait celui-ci :
Bien évidemment (sauf pour celui qui trouve "probant" son "test")Code:
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
Je suis étonné de l'absence d'autres réactions que la mienne.....
re
c'est du n'importe quoi nicolas
la formule pttopx utilise le z forcement que c'est pas bon la bonne blague
pour voir si c'est pointscreenpixels utilse une donnée numérique quelquonque et fait ton calcul prend une calculette tu aura la même
comment veux tu que pointtoscreenpixels te donne une donnée bonne a 2 zoom différents si le zoom n'est pas régulier
la bonne blague
c'est pas compliqué
prend la cellule A1 donne lui une dimension que tu veux
fait le test avec [B1].left a 2 zooms différent
et fait le même teste avec la donnée numérique correspondant a la dimension fois le coefficient zoom (1.1 pour 110,1.2pour 120,etc......
hoh!! ben ca alors ca donne pas pareil
prends une calculette et refait le calcul avec la donnée numérique tu verra
fait aussi la comparaison avec ppx du regedit qui lui au moins est sur
exemple
ma cellule est a 60 de left en zoom 100 test pointtoscreenpixels
et fait la même chose avec celui du regedit et même celui des api
maintenant applique un zoom n'importe le quel
test
maintenant fait la même chose avec le chiffre 60 a la place de la cellule.left applique le coefficient zoom correspondant au même que tu a utilisé précédemment je dis bien coefficient zoom
surprise surprise
bref je suis impatient de voir le résultat de l'expérience que tu veux faire
encore la preuve que tu manipule ce que je dis
le chiffre en point est bon oui mais en réalité visuellement non!!!!!!
il faut vraiment que je la face cette capture au ralenti ????????
et c'est pour ca que pointstoscreenpixels ne donne pas bon car lui respecte le 1.3333..... ou 1.66666.....
vous étés pas miro que je sache
Pièce jointe 291713
regardez bien comment la cellule évolue au fur et a mesure du zoom
j'ai pas la berlue bon sang!!!
et le must !! c'est que selon le dpi 96 ou 120 la modification zoom VISUELLE le shema de grossissement ou pas du height par le zoom est diffèrent 120 1 sur 3 ;96 des serie de 3 ,de 6 et de 2
Tu sais quoi, patricktoulon ?
Tu n'as toujours pas compris le fonctionnement du zoom.
Je t'ai fait pourtant plus haut un petit dessin. Je t'ai pourtant dit à plusieurs reprises que ce que tu voyais n'était qu'un miroir par homothétie de ce (le réel) qui, lui, ne variait absolument pas.
C'est la base elle-même de tout cela, qui te fait encore très gravement défaut.
Ce que tu vois à l'écran (des images de cellules dont les dimensions - celle des images et non des cellules elles-mêmes- "varient") n'influe en aucune manière la réalité (la propriété height reste celle réelle et non celle de l' "image" et c'est cette seule réalité qui est la base des calculs de ton "test")
Tu peux modifier autant que tu veux le zoom, il ne modifiera pas cette réalité, mais uniquement l'image vue à l'écran (et rien d'autre). Et tu ne reprends nullement et nulle part dans tes "calculs" les dimensions de l'"image", mais celles, réelles, de la cellule (ses propriétés, demeurées inchangées).
Pour résumer (et cela aussi, j'ai eu l'occasion de te le rappeler ici et là, pas uniquement dans la présente discussion) : le zoom est un miroir homothétique et n'a rien à voir, ni de près ni de très loin, avec un "redimensionnement" des objets (du genre de celui, que je conteste également) que tu as déposé en contributions.
Tu devrais VRAIMENT commencer à t'intéresser à ces bases ELEMENTAIRES
Cher Ami Unparia ,
_ Dés le démarrage du sujet que j’ai proposé, il y a eu de ta part une certaine incompréhension du sujet #2 #6 #8.
Cela a été amplifié par ta remarque surprenante #21
J'ai repris cela au #426 mais sans réponse à mes propres interrogations.
_ Lors de ta longue expérience as-tu constaté comme moi que dans ce milieu informatique il peut exister une ambiance de travail en équipe agréable malgré des erreurs ? Une fois de plus je félicite tous les participants toi y compris pour la ténacité lors de ce très long forum (voir le nombre d’accès à ce jour).
_ Certes, le sujet d’origine s’est un peu déplacé. J’attends quand mm de cette étude la finalité adaptée à mon cas.
_Tu as, me semble t-il en arrière plan des idées certainement intéressantes et très généralistes(que malheureusement je ne comprends pas toujours).
Il en est de mm des accès de haut niveau sur lesquels tu sembles pouvoir t’appuyer #401 #403 #405 Et dont j’attends la suite
Bravo à vous tous.
c'est fou caCitation:
Je t'ai fait pourtant plus haut un petit dessin. Je t'ai pourtant dit à plusieurs reprises que ce que tu voyais n'était qu'un miroir par homothétie de ce (le réel) qui, lui, ne variait absolument pas.
oui oui oui j'ai très bien compris ton point de vu
même si visuellement c'est pas pareil si on fait un .height on obtiens toujours pareil j'ai compris et cela sans toi
alors en effet on se demande pourquoi pointstoscreenpixels donne faux
non!!! il ne donne pas faux mais a la hauteur du défaut d'affichage du zoom
ce qui veux dire que pointstoscreenpixel donne vraiment ce que l'on voit a l'écran et pour cause c'est son rôle !!!!
puré de puré essaie pointstoscreenpixels sur un activX dans un userform point to pixel et vise et versa tu verra ya pas d'erreur
Pièce jointe 291718
je vais aussi m'intéresser au fait qu'il est membre des deux object et que selon l'object utilisé ca donne pas la même chose
A Patricktoulon
Tes "puré de puré" ne sont, désolé de te le dire, que pédalages dans une choucroute qui t'échappe selon toute évidence totalement.
Le pire est lorsque tes messages successifs finissent par se contredire.
Tout cela est ce que j'exècre le plus au monde.
Nous allons RESUMER :
- toi, tu t'évertues à installer des "rustines" en fonction d'environnements
- moi (je devrais dire "nous"), je m'évertue (nous nous évertuons) à démontrer une faille d'une méthode. Nous en demanderons soit la correction, soit la suppression de cette méthode dans la liste de celles annoncées comme "efficaces". Dans un cas comme dans l'autre : toutes tes "rustines" au "cas par cas" n'auront plus le moindre intérêt.
Voilà !
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
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 changeCode:
2
3
4
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
t'es pas miro non ?Code:
2
3
4
5
6
7
8
9
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
Non m'sieu !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
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 ...
pour une fois nous somme d'accords sauf que c'est pas pour les même raisonsCitation:
mais l'inefficacité de la méthode PointsToScreenPixelsX à tenir inclure ce "z" dans ses calculs
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
c'est la TA croyance.Citation:
ca ne le fait pas pour la simple et bonne raison que la partie que vaut ptscpxs(0) est faussé par le zoom
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:
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
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 :
voilà.Code:
2
3
4
5
6
7
8
9
10
11
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
elle est pas belle la série la hein !!Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
maintenant reprends la valeur du zoom 100 soit 46Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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
maintena que l'userform est a ffiché place le dans la range qui nous a servi pour ses dimensionsCode:
2
3
4
5
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
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 xCitation:
maintenant reprends la valeur du zoom 100 soit 46
et multiplie le par 1.2 pour le zoom 120 ca fait combien hein !!?????
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 :
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:
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
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é ...Citation:
et ne me dis pas que c'es pointstoscreenpixels le test avec setcursorpos démontré toute a l'heure prouve bien le contraire
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 :
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 ?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 ....
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
Ah ! ...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
"et devine quoi" (puisque tu aimes l'expression) :
en zoom 100%, tu n'as aucune modification de b dans l'équation, pardi ! Elle est bien bonne.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 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
mais c'est bien le grossissement le fond du problèmeCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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".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
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
toute la différence est là, patricktoulonjCitation:
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
- 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.
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 zoomCitation:
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
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
dans cette approche "du relatif (au cadre de excel)" , effectivement il faut intégrer le calibrage des barres x/yCitation:
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
(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 --->>
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.Code:
2
3
4
5
6
7
8
9
10
11
12
13
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
