Discussion :

[unparia]

je te promet que si tu me la donne je travaillerais dessus sans la dévoiler et te ferais part de mes constatations en MP

Tant que je ne te verrai pas savoir sérier les problèmes : pas question !

Commence donc par corriger ton code pour qu'il place correctement le curseur. Ce n'est pas le cas du code que tu montres et qui, pour l'essentiel, est quasiment identique au mien ***** (Franck te le confirmera). Il lui manque une gestion additionnelle qui fait appel à l'arithmétique.
Je l'ai dit et redit : La détermination précise des coordonnées en pixels, par rapport à l'écran, de l'angle supérieur gauche de la cellule traitée est le seul point intéressant de cette "affaire" et je n'en traiterai pas d'autre (j'ai également dit que le placement d'un userform à ces coordonnées était autre chose et s'avèrera totalement à éviter ... pour des raisons évidentes... sauf à faire encore d'autres calculs arithmétiques conditionnels ).

***** sauf que le tien, sans fonction additionnelle, "tape à côté" assez visiblement souvent et que le mien ne "tape à côté" que de vraiment très peu et assez rarement.

[unparia]

coucou Patrick
Mes tests et observations m'ont conduit aujourd'hui à une découverte.
Si avérée et confirmée --->> je vais te faire un petit cadeau unparien dans ta contribution
https://www.developpez.net/forums/d1...pi-window-gdi/

(sans rien d'autre que Excel - ni "api", ni lecture du registre par quelque moyen que ce soit ... VBA/Excel tout seul).

[patricktoulon]

j'ai vu dans ma contrib
si j'ai bien compris ce que j'ai vu avec "int" selon la marge des décimales *100 tu détermine un dpi
trop crevé ce soir pour décortiquer mais je regarderais a tète reposé

[patricktoulon]

bon la j'ai ma journée qui a été très dure dans la tète mais tout de même

je suis très surpris des résultats que j'obtient
en 120 dpi j'ai modifier "100.25" jusqu'à 100.96 et a ma grande stupéfaction on a toujours 120 dpi

par contre j'ai débuguer les .rowheight et .height et j'ai des résultats surprenant (un arrondi ahurissant) et me grave je dirais

ca confirme en ce qui me concerne une bonne fois pour toute que ptscrpix est juste et bien la propriété qui lui est injecté qui est fausse

la capture ce dessous parle d'elle même
il faudra m'explique pourquoi en lecture les propriété ne donne pas la même chose je l'ai d'ailleurs déjà signalé plus haut dans la discussion


sérieux jacques avec cette P... de journée passée que j'ai subit tu me pose une colle pareille sachant que je vais pas lâcher le morceau tant que je vais pas trouver la réponse, t'es pas gentil

[unparia]

en 120 dpi j'ai modifier "100.25"

Cette valeur n'est pas choisie au hasard ! Il ne faut pas la modifier.

par contre j'ai débuguer les .rowheight et .height et j'ai des résultats surprenant (un arrondi ahurissant)

et c'est très précisément tout ce qu'il y a à comprendre pour affiner tes résultats dans la très longue discussion en cours (la détermination des coordonnées/écran en pixels d'une cellule). Je t'y ai parlé d'une fonction additionnelle, non ? Elle s'en sert.

[patricktoulon]

ok
testé en 96 et 120 ca marche pour le dpi

mais il y a aucune logique la dedans dans le sens ou les opérande de ta formule tu les obtient par la lecture de la propriété et elles sont fausses

dans ta formule remplace 100.25 par de 100.12 à 100.27 tu aura le même résultat car en lecture la propriété te donne 100.2

je dirais même mieux de 100.28 a 100.4 ca te donne 100.4 et le dpi est pourtant bien identifié en 96 ou 120 j'ai testé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Sub test_patrick()
    With ActiveSheet.Range("A" & Rows.Count - 1)
        anc = .RowHeight:
        For i = 100.12 To 100.28 Step 0.01
            .RowHeight = i
        Debug.Print "pour " & i & " appliqué  j'ai  un rowheight obtenu en lecture  de " & .RowHeight
        Next
    End With
End Sub

alors comme ca c'est facile on a le départ et l'arrivée

sauf que dans notre exercice on a que l'arrivée a savoir la propriété en lecture (et donc fausse)

donc va savoir pourquoi ca fonctionne pour connaitre le dpi mais bon OK ca en fait une de plus

maintenant pour ce qui est de l'ajustement et d'en récupérer le différentiel je te souhaite bon courage ayant que la valeur de la propriété en lecture

alors oui en faire une fonction et le faire sur le rowheight de la cellule concernée OK mais on a pas la valeur de départ a moins de faire la modif et revenir et récupérer le différentiel comme tu le fait dans ton exemple

ma fois je ferais des test d'intégration de ce principe mais je ne suis pas convaincu

en tout cas même si ca tombe juste ca n'est pas logique

entendons nous bien je parle pas de ta formule en disant que c'est faux mais bien des propriétés (.rowheight et .height ) regarde le debug

[unparia]

mais il y a aucune logique la dedans

Tu crois ? Tu te trompes.
J'ai choisi cette valeur (j'aurais pu en choisir d'autres, mais toutes en m'assurant que le choix fait facilitait la distinction entre modulos appliqués. ) pour une seule et bonne raison. Cette raison est purement arithmétique (les modulos sur un tel nombre - sa partie décimale, en fait - sont parfaitement distinguables en fonction des dimensions acceptées par Excel et répondant à une cadence très distincte selon le DPI.

Je comprends que ce mécanisme t'échappe. Il est pourtant classique et des mécanismes similaires sont appliqués dans de nombreux domaines physiques.
Tes remplacements par d'autres valeurs n'ont aucun sens du fait qu'il ne permettent pas de distinguer. Tu connais la preuve par 9 ? Oui, n'est-ce pas ?
Elle participe d'un principe similaire. Essaye donc la preuve par 8, par 7 , etc ... tu ne pourras pas, hein ...

Que te dire, Patrick, sinon que tu t'égares sur le sens du choix d'une valeur. Une autre fois : j'aurais pu en choisir d'autres, mais pas au hasard.

Tu sais quoi, Patrick ? Je ne connais absolument rien en aviation. Je m'abstiens dès lors de m'en mêler.

EDIT : et tiens ... Tu sais quoi ?
Même en bavardant (assez stérilement) je viens d'étendre le mécanisme. Il est maintenant capable de déceler les dpi 96, 120, 144 et 192 (et toujours avec la même valeur de départ, 25 n'ayant pas les mêmes divisions (et donc le même modulo) selon différents diviseurs cadencés.
Va donc faire un tour dans la discussion adéquate (celle concernant le dpi).

[patricktoulon]

Que te dire, Patrick, sinon que tu t'égares sur le sens du choix d'une valeur. Une autre fois : j'aurais pu en choisir d'autres, mais pas au hasard

détrompe toi j'ai très bien compris
ce qui me gène a moi c'est que les deux valeurs ci dessous en couleur rouge et bleu ne correspondent pas a la valeur en vert
les somme en rouge et bleu ici en l'occurrence sont arrondies a 100.2 même si je met par exemple 100.14
et npon seulement elles sont arrondies mais en plus c'est même pas la règle de base qui est appliquée a savoir 0.16=arrondi au supérieur--> 0.2

mais l'arrondi se fait de 0.1 a 0.27--->0.2 soit 0.26 points de flottant que l'on multiplie par le nombre de rows pour la cellule prise en compte dans l'exercice ca fait beaucoup

et encore même la c'est même pas le cas puisque les écarts ne se font pas avec le nombre de cellules mais par série

alors a quoi pourrait bien me servir ce calcul si ce n'est oui de me donner le dpi puisque apparemment il le donne mais c'est tout

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
anc = .RowHeight: .RowHeight =  100.25   '100.14
        If (.Height - Int(.Height)) * 100 Mod 25 = 0 Then dpi = 96 Else dpi = 120

 Debug.Print .RowHeight & vbCrLf & .Height & vbCrLf & .Height & vbCrLf & Int(.Height)

100,2
100,2
100,2
100

EDIT: et de plus je viens de faire le test sur le portable j'ai encore une réaction différente par rapport au fixe les limites base et haute arrondies sont différentes

[unparia]

alors a quoi pourrait bien me servir ce calcul si ce n'est oui de me donner le dpi puisque apparemment il le donne mais c'est tout

Ben ... comme tu le dis : à te donner le dpi.
Et c'est la raison pour laquelle ce code n'est pas ICI, mais dans la discussion relative à la détermination du DPI, hein ...

Par contre, il aurait pu déclencher chez le Toulonnais certains déclics intéressants. Je vois que tel n'est pas le cas. Tant pis pour lui --->> je ne vais pas interrompre d'autres calculs et réflexions juste pour lui expliquer comment utiliser astucieusement certains aspects et prendre à nouveau le risque de passer des pages et des pages à en débattre stérilement. Cela me retarderait. Il attendra donc les résultats éventuels, hein ...
Amitiés

EDIT : une perche (et la dernière car si tu ne sais pas la saisir, tu ne sauras rien saisir de tout le reste) : ne pas raisonner uniquement en arrondis et commencer à penser cadence.
La fonction utilisant une conjugaison des deux ne sera certes pas facile à écrire, notamment pour les dpi élevés.
Et oublier un "lien" avec le nombre de lignes (j'y ai également "cru" il y a plusieurs jours et ..... temps perdu).
Les "apparences", Patrick, sont souvent assez trompeuses. Elles tendent à encourager (à tort) des dispersions diverses aboutissant à des impasses non moins diverses.
Question : on ne chasse pas l'alouette, dans le Var ? Si oui : comment ?

[patricktoulon]

Bonjour jacques

ne pas raisonner uniquement en arrondis et commencer à penser cadence.

j'ai très bien compris au contraire

toi tu parle de cadence moi de série et cela depuis un moment déjà mais on parle de la même chose

après tout a fait d'accords ,faut il encore coder cela j y avais fait allusion il y a quelques pages en parlant des pairs et impairs et/ou nombre premiers qui semblaient me donner des résultats intéressants

mais j'ai pas poursuivi dans cette ligne

[pijaku]

Patrick, Bonsoir,
Autant j'ai cru observer la même chose que toi concernant les lignes paires et impaires en DPI120***, autant les nombres premiers tu dois oublier ca de suite.
Attention, je ne nie pas ton observation, je dis juste que ça n'était qu'une coïncidence qui ne te mènera nulle part.

*** en l'occurrence, ca m'est arrivé d'observer ce comportement, sous une ligne dont j'avais changé la hauteur, mais pour une valeur spécifique, que je n'ai pas notée. .........

[unparia]

Coucou
Je pars pour une longue partie de pêche.
A Franck : Je t'enverrai cette nuit le code final (détermination très précise des coordonnées/écran, en pixels, de l'angle supérieur gauche de la cellule spécifiée), quels que soient (et sans les intégrer dans mon code) le dpi (96,120,144 ou 192) et le zoom. Je suis parti d'une idée que tu avais exposée, que j'ai "transformée"
A Patrick : je déposerai ce code demain avant midi. Tu as donc encore le temps de me prendre de vitesse
A plus.

[pijaku]

Bonsoir Jacques,
Très bonne nouvelle.
Je testerai volontiers ta fonction demain.

Heureux d'avoir mis mon petit caillou à l'édifice.

Bonne soirée.

Amicalement,
Franck

[patricktoulon]

re
oui pijaku j'avais éliminer cette piste car sur divers PCs les résultats étaient différents

d'ailleurs pour l'histoire du (.height-int(.hright)) les résultats sur mes 4 pc sont différents je parle bien sur des (cadences/séries)

et cela ne se produit pas forcement sur les OS différent, mon fixe et mon portable Pro tournent sur W7

sur le portable cobaie W10 et une autre partition vista

sur mon nouveau portable W10

les deux portable en os W10 donne aussi des séries différentes

je me langui que l'on trouve c'est une horreur ce w10 vite vite que je le vire

@jacques je testerais moi aussi

[Xlcro]

Bonjour,

J'ai lu une centaine des messages de ce forum, particulièrement les premiers et les derniers. La discussion prend fin au message 1114 sur un bel espoir, mais s'il y a eu une suite, les messages subséquents ne sont pas accessibles. Je me permets de réactiver cette discussion, car en m'inspirant de votre travail, je suis arrivé à un résultat tellement surprenant, que j'aimerais que vous me confirmiez si cela tient la route, ou si je n'ai finalement rien compris au problème que vous tentiez de solutionner.

Pour rappel, l'objectif initial de la discussion est de trouver comment positionner la flèche de la souris sur une cellule sélectionnée, cela quelque soit la taille de la feuille affichée et son positionnement sur l'écran. Autrement dit, il s'agit de trouver les coordonnées d'écran en pixels d'une quelconque cellule sélectionnée. C'est exactement le problème qui s'est posé à moi dans une application où l'usager devait avoir la possibilité d'afficher un menu contextuel personnalisé de type PopUp sur une cellule quelconque de la grille, sans toutefois utiliser la souris, l'application devant être accessible aux non-voyants, moi y compris.

En observant les valeurs retournées en diverses situations par les méthodes PointsToScreenPixelsX etPointsToScreenPixelsy de l'objet ActiveWindow.ActivePane, j'ai réalisées que lorsque la cellule cible est activée pour la rendre visible, les coordonnées d'écran retournées sont alors exactement celles que l'on cherche.

Pour illustrer ce fait, je reproduis, ci-après, l'essentiel du message # 2 d'une discussion que j'ai récemment ouverte et que je fermerai si vous me confirmez que mes résultats tiennent la route.
Ouvrir à partir du clavier un menu contextuel à proximité immédiate de la cellule active.

Pour afficher un PopUp à un endroit donné, disons le coin supérieur gauche d'une cellule quelconque, la méthode ShowPopup de l'objet CommandBar exige qu'on lui précise en pixels les coordonnées d'écran de ce point. On y parvient en activant la cellule cible, pour qu'elle devienne visible, et en utilisant comme suit l'objet ActiveWindow.ActivePane :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
ActiveSheet.Cells(150,32).Activate ' Choix arbitraire
Dim CX As Variant, CY As Variant
With ActiveWindow.ActivePane
   CX = .PointsToScreenPixelsX(ActiveCell.Left)
   CY = .PointsToScreenPixelsY(ActiveCell.Top)
End With
Application.CommandBars("MaBarre").ShowPopup CX, CY

La barre de commande doit être de type msoBarPopup, sinon la méthode ShowPopup échouera. Si les coordonnées x et y ne permettent pas d'afficher la totalité du menu contextuel, elles seront modifiées pour que le menu devienne entièrement visible.

Tout semble fonctionner correctement, peu importe le zoom appliqué ou la position de la fenêtre Excel sur l'écran. Si vous avez un moment pour expérimenter le code fourni plus loin, vos commentaires seraient appréciés, cela permettrait de vérifier si la méthode est valable dans tous les environnements.

Les valeurs retournées par PointsToScreenPixelsX et PointsToScreenPixelsy peuvent être confondantes. Pour les interpréter correctement, il faut savoir que ces fonctions ne font pas seulement une conversion entre les unités "points" et les unités "pixels". Elles opèrent également un changement de référentiel, la grille Excel et la grille de l'objet ActivePane n'ayant pas la même origine.

Sur la grille Excel, les coordonnées Left et Top d'une cellule sont exprimées en points, et mesurent l'éloignement de ce point par rapport au coin supérieur gauche de la cellule a1, qui est le point (0,0). Ces coordonnées ne sont donc jamais négatives. Pour le référentiel ActivePane, l'origine est plutôt le coin supérieur gauche de l'écran. Les coordonnées retournées par les méthodes PointsToScreenPixelsX/y précisent en pixels l'éloignement relatif d'un point par rapport à cette origine. Il en découle qu'un pixel situé à Gauche de cette origine aura une abscisse négative, de même qu'Un point situé au -dessus aura une ordonnée négative.

Il faut également noter que les défilements horizontal ou vertical de l'écran n'affectent pas le système de coordonnées de la grille Excel. Par contre, pour le référentiel ActivePane, à chaque fois que l'écran défile, tous les points se déplacent par rapport à l'origine, de sorte que toutes leurs coordonnées changent.

L'utilisation de l'objet ActiveWindow.ActivePane de cette manière, pourrait s'avéré utile partout où la connaissance des coordonnées d'écran est nécessaire. Dans certains cas, il peut être justifié de déplacer automatiquement le pointeur de la souris sur une cellule donnée. L'opération devient triviale en utilisant l'API SetCursorPos avec les coordonnées obtenues de l'objet ActivePane.

Le code suivant illustre l'affichage d'un popUp au coin supérieur gauche d'une cellule quelconque. Tout mettre dans un module standard, puis exécuter la macro PrepareMenuContextuel. Se déplacer vers une cellule quelconque et faire ALT + FlècheBas . Lorsque le menu apparaîtra, il affichera les coordonnées en points et en pixels de la cellule active. Si vous activez une optionde de menu, un MsgBox confirmera les coordonnées effective du PopUp.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
38
39
40
41
42
43
44
45
46
47
 
Option Explicit
 
Sub PrepareMenuContextuel()
Dim CB As CommandBar, CBC As CommandBarControl
Application.OnKey "%{DOWN}", "AfficherMenuContextuel"
On Error Resume Next
Application.CommandBars("MaBarre").Delete
On Error GoTo 0
Set CB = Application.CommandBars.Add( _
   Name:="MaBarre", Position:=msoBarPopup, temporary:=True)
Set CBC = CB.Controls.Add(Type:=msoControlButton, before:=1, temporary:=True)
CBC.Style = msoButtonCaption
CBC.Caption = "Option 1"
CBC.OnAction = "AuTravail"
'
Set CBC = CB.Controls.Add(Type:=msoControlButton, before:=2, temporary:=True)
CBC.Style = msoButtonCaption
CBC.Caption = "Option 2"
CBC.OnAction = "AuTravail"
Set CBC = Nothing
Set CB = Nothing
End Sub
Sub AfficherMenuContextuel()
' Afficher le menu contextuel au coin
' supérieur gauche de la cellule active
Dim CX As Variant, CY As Variant
With ActiveWindow.ActivePane
   CX = .PointsToScreenPixelsX(ActiveCell.Left)
   CY = .PointsToScreenPixelsY(ActiveCell.Top)
End With
'
CommandBars("MaBarre").Controls(1).Caption = _
   "Coordonnées en points (" _
   & ActiveCell.Left & "," & Activecell.Top & ")"
CommandBars("MaBarre").Controls(2).Caption = _
   "Coordonnées en pixels (" & CX & "," & CY & ")"
'
Application.CommandBars("MaBarre").ShowPopup CX, CY
'
End Sub
Sub AuTravail()
With CommandBars("MaBarre")
   MsgBox "Coordonnées effectives du Popup (" _
      & .Left & "," & .Top & ")"
End With
End Sub

[patricktoulon]

bonjour
sacré déterrage
oui ca a été résolu de la même manière depuis longtemps
en effet pointstoscreenpixel(x,y) donne tout ce dont on peut avoir besoins

le coin gauche haut de la grille par rapport a l'écran left = pointstoscreenpixelx(0) top= pointstoscreenpixely(0)
remplacer les 0 par le left ou top des cellules pour leur position a l'écran

mieux encore
donne le coefficient point to pixels en fonction du DPI

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Sub test()
With ActiveWindow.ActivePane
ptopx = (.PointsToScreenPixelsX(Cells.Width) - .PointsToScreenPixelsX(0)) / Cells.Width
End With
MsgBox ptopx
End Sub

bref oui résolu

[Xlcro]

Bonjour Patrick,

Oui, sacré déterrage. Une épopée cette discussion.
Ça m'a pris 3 semaines de galère pour trouver la solution, pas moyen de trouver sur Google.

Merci pour la confirmation et les infos supplémentaires.

Dans mon code j'utilise Alt + FlècheBas pour ouvrir le menu contextuel.
J'aurais préféré utiliser la touche Menu, mais Onkey, ni sendkey d'ailleurs, ne permettre de spécifier la touche vbKeyMenu.
Pourtant, dans vba-Word KeyBinding est plus souple.

Croyez-vous qu'il est possible de reprogrammer la touche Menu dans Excel?


Merci encore.

Pierre

[patricktoulon]

re

Croyez-vous qu'il est possible de reprogrammer la touche Menu dans Excel?

tu parle de quelle touche?
et tu devrais ouvrir ton propre post histoire de laisser celle ci tranquille