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

patricktoulon

XLDnaute Barbatruc
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
 
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
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.
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
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.
 

Pièces jointes

  • ExactVisibleRangeSize.xlsm
    45 KB · Affichages: 1
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
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...
 

Pièces jointes

  • ExactVisibleRangeSize.xlsm
    46 KB · Affichages: 1
Vote positif 0 Vote négatif

patricktoulon

XLDnaute Barbatruc
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
 
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
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.
 
Dernière édition:
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
@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.
 

Pièces jointes

  • Pixels Points conversion.txt
    2.6 KB · Affichages: 3
Vote positif 0 Vote négatif

patricktoulon

XLDnaute Barbatruc
re
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
 
Vote positif 0 Vote négatif

TooFatBoy

XLDnaute Barbatruc
Dudu2 à dit:
Il y a plusieurs manières de faire ce calcul. Via les API ou indirectement, j'ai toute une liste.
Cliquez pour agrandir...
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 !
 
Vote positif 0 Vote négatif

patricktoulon

XLDnaute Barbatruc
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
 
Vote positif 0 Vote négatif

Dudu2

XLDnaute Barbatruc
Moi, j'avoue que je fais un blocage sur ce problème.
Cliquez pour agrandir...
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...
 
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…