XL 2016 VBA - Exact Visible Range

[Dudu2]

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 ?

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

 

[Dudu2]

@patricktoulon,
Ok merci pour ce code.
Je regarde ça demain. Là je suis out of order

 

[patricktoulon]

resultat mode fenêtré

resultat mode fullscreen

j'ai un petit défaut à droite par ce que j'ai bâclé le truc , mais bon tu devrais trouver
perso je préfère pas assez que trop je peut te suggérer que si le dlgframe saute en maximisé le sm-border devrait reprendre la main normalement donc getsystemmetrics(5)*2 (gauche et droite) et on devrait avoir le ponpon

je récapitule bidule
mode maximisé le dlgframe saute (grosse bordure et ombre) et les petite bordure reprennent la main donc +2

mode fenêtré
le dlgframe reprend la main et le sm_border saute donc 0 car il est inclu dans le dlgframe

demain je te montrerais sur un userform comment est le cadre de ta fenêtre quand il est maximiser en la gardant fenêtré

bonne nuit les pettis
bonne nuit

 

[Dudu2]

Bonjour les chercheurs du visible,

Chez moi ce fichier marche assez bien.
J'ai juste ajouté dans le traitement les SM_CXDLGFRAME et SM_CYDLGFRAME à l'instar de @patricktoulon.

Concernant le problème de @sylvanu, je pense que c'était la méthode de récupération du ratio Pixel / Point via le registre qui ne fonctionne pas en 2007 et je suis revenu sur mon module traditionnel API pour le récupérer.

J'ai toujours des constantes dont je n'arrive pas à me débarrasser car aucune info, et sûrement pas avec le GetSystemMetrics, n'est disponible pour en déterminer les valeurs.

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

Ce serait bien de trouver de l'info, au moins sur la StatusBar.

A noter que j'ai essayé de travailler en RECT (Pixels en Long) mais les conversions Double (des points) en Long (des pixels) introduisent des petites différences gênantes pour la précision. Comme les dimensions d'une Window sont en points, je suis resté en points pour les calculs.

 

[patricktoulon]

Bonjour @Dudu2
résultat mode fenêtré
un poil a gauche de trop il manque presque rien
un peu plus pas assez en top

résultat mode fullscreen
on peut considérer que c'est bon

 

[Dudu2]

Le calcul de la taille de la fenêtre est un exercice difficile.
Dans cette version je suis passé en API avec le GetWindowRECT juste corrigé quand la fenêtre est maximisée.

Je pense que ça correspond à la taille réelle, mieux que les Window.Top/Left/Width/Height car lorsque je cadre la fenêtre à droite (touche Win + flèche droite) j'ai bien un Top = 0 alors que le Window.Top = 1 !!!

Je ne crois pas pouvoir faire mieux...

 

[Dudu2]

J'attends vos retours pour valider, @TooFatBoy, @sylvanu, @patricktoulon.

 

[patricktoulon]

re
Const StatusBarHeightPixels = 26
c'est là ou tu fait erreur
chez moi en dpi 100 ,26 pixels font 19.5
19.5 c'est la compilation de la status bar + les 3 du gldframe- le sm-border

pour info chez moi en point c'est 17+3 +1(statusbar +gldframe+sm-border)

le problème c'est que tu compile tout

alors oui dans un sens ça va (en full screen) mais quand tu n'est pas en fullscreen ça va plus même si on est pas loin

 

[Dudu2]

La question c'est pas combien de points font 26 pixels, puisque j'utilise l'API pour convertir.
Donc chez toi, 26 pixels seront bien convertis en 19.5 points.
Que ce soit en Full Screen ou en réduit, la Status Bar ne change pas de hauteur.

Ça me parait assez simple, et je ne vois pas comment tu peux décomposer la hauteur de la Status Bar avec de DLGFRAME et des BORDER. Y en a pas.

La question est est-ce que la Status Bar fait bien 26 pixels chez toi, et ailleurs. Problème des constantes.

Edit: Pour la taille de l'Exact Visible Range j'ai tenu compte des DLGFRAME de la fenêtre, mais je n'ai pas tenu compte des BORDER de la fenêtre. Je vérifie à les introduire sous la même condition ed non maximisation de la fenêtre.

Edit: Faudra aussi traiter le Zoom dont les calculs ne sont pas toujours très précis.

Edit: Je vais travailler en pixels puisque je suis sur la base d'un GetWindowRECT.

 

[TooFatBoy]

La question c'est pas combien de points font 26 pixels

Ça tombe bien parce que je pense que c'est impossible à calculer puisque :
- 1 point a une taille fixe de 254/72 mm,
- 1 "pixel" a une taille qui dépend de la résolution d'affichage.

 

[Dudu2]

@TooFatBoy,
Il y a plusieurs manières de faire ce calcul. Via les API ou indirectement, j'ai toute une liste.
Perso je préfère via les API car c'est exact en toutes circonstances et, si @sylvnu confirme, valable pour les anciennes version d'Office.

In extenso ça donne ça.

 

[patricktoulon]

re

Donc chez toi, 26 pixels seront bien convertis en 19.5 points.
Que ce soit en Full Screen ou en réduit, la Status Bar ne change pas de hauteur.

Ça me parait assez simple, et je ne vois pas comment tu peux décomposer la hauteur de la Status Bar avec de DLGFRAME et des BORDER. Y en a pas.

et oui on c'est pas compris
je ne la décompose pas pour moi elle fait 17 et non 19.5
c'est sa fenêtre parent qui change en mode fenêtré ou fullscreen (C'EST CA QUE TU DOIS COMPRENDRE )
Donc pour faire un Calcul """EXACT""" il te faut partir de la base
ma status bar fait combien
la fenêtre parent est elle fenêtré ou maximisée
mes bordures fenêtre parent font combien en fonction du windowsate
etc....
il n'y a que comme ça que tu peux avoir un calcul exact autrement tu n'a qu'une approximation plus ou moins bonne
d'ailleurs quand je regarde avec mon getsystemMetricscontroller

 

[TooFatBoy]

Il y a plusieurs manières de faire ce calcul. Via les API ou indirectement, j'ai toute une liste.

D'après ce que j'avais constaté quand on avait fait des recherches là-dessus avec ton copain, les API ne donnent pas les bonnes valeurs.

Par exemple, moi je suis 111 dpi et l'API me donnait 96, et lui était (de mémoire) en 32 dpi et l'API lui donnait une valeur différente de 32.

Moi, j'avoue que je fais un blocage sur ce problème.
Lui, ça ne le dérangeait pas d'avoir des valeurs fausses... Mais je crois qu'il n'a toujours pas compris ce qu'est un "dpi". Ce qui ne l'empêche pas d'arriver à placer un UserForm pile-poile au bon endroit sur un écran !

 

[patricktoulon]

regarde capture fenêtre et capture fullscreen

 

[patricktoulon]

D'après ce que j'avais constaté quand on avait fait des recherches là-dessus avec ton copain, les API ne donnent pas les bonnes valeurs.

Par exemple, moi je suis 111 dpi et l'API me donnait 96, et lui était (de mémoire) en 32 dpi et l'API lui donnait une valeur différente de 32.

Moi, j'avoue que je fais un blocage sur ce problème.
Lui, ça ne le dérangeait pas d'avoir des valeurs fausses... Mais je crois qu'il n'a toujours pas compris ce qu'est un "dpi". Ce qui ne l'empêche pas d'arriver à placer un UserForm pile-poile au bon endroit sur un écran !

Bonjour @TooFatBoy (le copain)
comment dire ça?je sais plus trop
il y a deux politiques
1° l'affichage géré par le processeur graphique de la carte graphique
2° l'affichage géré par le processeur de ta carte mère

moi j'ai choisi depuis la fin de mon utilisation de Win 7 d'utiliser le processeur de la carte graphique
du coup c'est un poil plus précis
du coup aussi comme la représentation à l'écran n'est qu'une simulation(de la même façon qu'avec les drivers MS par défaut) en terme de résolution et de DPI
vous vous dites ça ne coïncide pas avec vos calculs
mais en fait si ! le mot clé c'est "simuler"
d'ailleurs depuis 2017 dans le panneau de config des cartes graphique le mot simuler est entre parenthèses
je suppose que la raison est que nous ne sommes pas les seuls dans ce débats

un autre avantage ET PAS DES MOINDRES c'est qu'avec les pilotes et bus de la carte graphique
fini le problème de dpi 96 ,111, 120 ,150, etc...
c'est simuler en 96 que je sois en zoom window 100/125/etc... contrairement à windows 7 d'origine
du coup je n'ai pas le problème de @Dudu2 qui lui est en 0.6 au lieu du 0.75 qui correspond au coeff pixel et cela universellement
1/0.75= 1.333333333333333 Ca c'est universelle
maintenant si vous utilisez les driver générique MS il vous faut le retravailler avec le DPI simulé par MS
parti de la comme toi tu est en 111 réellement tu a des petits défaut

pour ma part comme je simule du dpi 96 partout ben je n'est pas le souci
car je simule du 1600X900 en 1080i

 

[Dudu2]

Moi, j'avoue que je fais un blocage sur ce problème.

C'est trop compliqué pour moi.

Concernant la question de l'ExactVisibleRange une des problématiques est déjà de savoir ce qu'on veut retourner ! Pour l'instant je rame et je reprendrai plus tard.

En tous cas, j'en apprends un peu plus sur les Window qui remet en question des acquis validés sur des approximations. Va falloir revoir du code...