Ceci est une page optimisée pour les mobiles. Cliquez sur ce texte pour afficher la vraie page.

XL 2016 VBA - Exact Visible Range

Dudu2

XLDnaute Barbatruc
Bonjour,

VBA nous donne un Window.VisibleRange qui inclut les dernières colonne et ligne pas forcément complètement visibles.
C'est souvent handicapant quand on veut avoir un Window.ExactVisibleRange qui exclut les parties non visibles des dernières colonne et ligne.

J'ai dû faire un code sans trop d'API pour tenter de définir cet ExactVisibleRange mais hélas, j'ai aussi dû utiliser des constantes qui semblent valides chez moi. Mais le sont-elles chez vous ?
VB: 
Const VerticalScrollBarBordersPixels As Long = 2 * 2.5    'Borders around the Vertical Scroll Bar
Const HorizontalScrollBarBordersPixels As Long = 2 * 4    'Borders around the Horizontal Scroll Bar
Const StatusBarHeightPixels = 26

Merci par avance de tester ce code pour vérifier qu'en toutes configurations de fenêtre (maximisée et réduite), la Shape Rectangle s'affiche bien aux limites basses de la partie visible.
Si ce n'est pas le cas, un petit screenshot et des infos sur la version Window et Office (versions et bits)



Fichier: voir plus loin
 
Dernière édition:
Trier par date Trier par votes

Dudu2

XLDnaute Barbatruc
Je peux fixer ça mais ça ne m'arrange pas car chez moi ça va encore baisser la Shape qui est 1 pixel trop basse quand elle est encore 1 pixel trop haute chez toi.

Le seul critère de différence que je vois c'est la ratio point/pixel.
Ça donne quoi chez toi ?
 

Pièces jointes

  • Classeur1.xlsm
    24.5 KB · Affichages: 1
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
Donc tu partages ce taux de 0.75 en pixel to point conversion. Chez moi c'est 0.6.
Je n'ose croire que c'est ce qui fait la différence, ça n'a pas de sens.

Dommage que @sylvanu en ait eu marre (je le comprends), ça aurait fait un scénario de plus.
 
Vote positif 0 Vote négatif

TooFatBoy

XLDnaute Barbatruc
4 / 3 = 96 / 72

Donc Excel (ou Windows ???) considère que je suis en 96 dpi, alors qu'en réalité je suis en 111 dpi.
Il est évident que leur dénomination "dpi" est fausse.

Comme je disais précédemment, je comprendrais que 96 dpi soit utilisé par Excel (et même par Windows) dans ses calculs, s'il se basait sur le zoom de Windows.
Mais vu qu'on m'a dit que ça n'avait rien à voir avec le zoom, je ne comprends point...
 
Vote positif 0 Vote négatif

patricktoulon

XLDnaute Barbatruc
Donc Excel (ou Windows ???) considère que je suis en 96 dpi, alors qu'en réalité je suis en 111 dpi.
Il est évident que leur dénomination "dpi" est fausse.
Cliquez pour agrandir...
ha ben enfin ça rentre
le dpi n'est qu'une échelle qui opère par rapport a ton tes écrans
et je le prouve DÉFINITIVEMENT DANS LA VIDEO sans équivoque
@Dudu2 tu devrais prendre le temps c'est énorme
ça confirme tout ce que je dis depuis des années
je donnerais le code après que vous ayez vu (il est pas bien compliqué
le calcul tiens en deux lignes pour le width et height

c'est ENORME !!!!
 
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
@patricktoulon, j'ai vu l'essentiel je pense de ta vidéo.
Retirer les éléments 1 par 1 c'est en effet difficile. L'idée d'utiliser les UsableWidht/Height est très intéressante.
Je n'en avais rien tiré avant mais tu sembles montrer que c'est peut-être la clé.

Tu utilises le SM_CXMIN, mais qu'advient-il si les les Scroll Bar et/ou la Status Bar ne sont pas présentes ?
Je pense qu'il faut affiner avec ces 2 barres retirées des UsableWidht/Height au lieu du SM_CXMIN.
 
Vote positif 0 Vote négatif

patricktoulon

XLDnaute Barbatruc
bon je vois que tu a compris
pour le fait qu'elles soient présentes ou pas ,tu sais faire avec des if me semble t il non ?
non seulement c'est possiblement la clé mais ça montre bien ( ET SURTOUT SANS ÉQUIVOQUE)que ce qu'on voiT à l’écran ne reflète pas les calculs si on procède mathématiquement parlant
j'espère même si il est faché avec moi que @TooFatBoy en retiendra un minimum

RAISONNEMENT
USABLEWIDTH - GetSystemMetrics(SM_CYMIN) - GetSystemMetrics(SM_CXSIZEFRAME)
et pareil pour le height
Terminé
et même si tu vois un rond à la place d'un carré
c'est windows qui se charge de tout
 
Vote positif 0 Vote négatif

TooFatBoy

XLDnaute Barbatruc
TooFatBoy à dit:
Il est évident que leur dénomination "dpi" est fausse.
Cliquez pour agrandir...
Dudu2 à dit:
Ça dépend peut-être de comment il utilise ces 111 dpi !?
Cliquez pour agrandir...
Pour moi un dpi c'est un dpi. Un point (sans jeu de mot) c'est tout.

Si je me souviens bien, il y a pas mal de temps, plus on augmentait la valeur du zoom de Windows (120 % -> 150 % -> 200 %) plus la valeur "dpi" donnée par l'API augmentait aussi.

Il est évident que c'est impossible et que ça devrait être l'inverse.
Le gars avec qui on avait trouvé ça n'était absolument pas dérangé par ça, mais moi je bloquais dessus. Et à force de me creuser la soupière, j'avais réussi à échafauder une hypothèse qui me convenait parfaitement. Mais apparemment aujourd'hui la valeur renvoyée par l'API ne serait plus dépendante du zoom de Windows.


Mais toi, mon Dudu, as-tu trouvé pourquoi tu n'as pas 96 / 72 ????
 
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
Chez moi voilà ce que j'ai (c'est en pixels mais c'est pareil)

La hauteur ça fonctionne, mais le calcul différe du tiens.
VB: 
.Bottom = .Top _
        + Window.UsableHeight * PointToPixel _
        - CYMIN _
        - CYDLGFRAME _
        + StatusBarHeight

La largeur ça ne fonctionne pas, et je ne sais pas à quoi correspond cette marge à droite.
Code: 
.Right = .Left _
        + Window.UsableWidth * PointToPixel _
        - CXMIN _
        - CXDLGFRAME

Il manque 15 pixels à droite, et ça ne correspond à aucun SM.
 
Dernière édition:
Vote positif 0 Vote négatif
Identifiez-vous ou inscrivez-vous pour participer.
Menu
Connexion
S'inscrire
Les cookies sont requis pour utiliser ce site. Vous devez les accepter pour continuer à utiliser le site. En savoir plus…