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)

1732747330635.png


Fichier: voir plus loin
 
Dernière édition:

patricktoulon

XLDnaute Barbatruc
et si je test à 1 point d'épaisseur la bordure on la vois carrément plus
1732977915205.png


autrement dans les calculs ou l'ors de la création et positionnement le la shape il faut lefter de l’épaisseur et réduire de le width de l’épaisseur ( mathématiquement parlant cette fois ci pour la faire rentrer dans le cadre
du real visible range
 

Nicolas JACQUIN

XLDnaute Impliqué
Supporter XLD
Salut les copains,
@Dudu2, ça fait un moment que je suis votre conversation, ton fichier du post
https://excel-downloads.com/threads/vba-exact-visible-range.20085344/post-20669500
fonctionne chez moi, si tu fait 100, 105,110,120, 125 etc.. ça match, mais comme le problème des userform à une époque qui à pris du temps, si tu veux faire du 102, 103, 107, 123, 128 etc... c'est dans les choux, du moins chez moi.
Toujours les problèmes de zoom en faites.
@+
 

patricktoulon

XLDnaute Barbatruc
j'ai pigé!!!!!!!!!!!!!!!!!!!!!!
il a fallu que je test ce que j'ai dis pour comprendre
alors avec mon calcul de dégrèvement par rapport au bordures de shapes
j'avais raison sur le principe
mais l'orsque j'enleve les menu il me faut enlever 4 au width de la shape
4 c'est la bordure gauche+bordure droite
ca veux dire que windows met bien la shape à -2 donc bordure invisible mais ne le compte pas dans son redimensionnement
et de plus encore
si ma bordure de shape fait 2

si je fait -2 textuellement ou -.line.weight là encore j'ai des nuances certes vraiment minimes mais visible quand même

tout ces exo confirment ce dont je suis convaincu depuis des lustres
a savoir windows affiche ce que tu lui demande à son echelle Dpi
démonstration
VB:
Sub test()
    Dim shap As Shape, R As rectanglePlus, z#
    z = ActiveWindow.Zoom / 100
    R = GetRectangleVisibleRange
    'supprime la shape si elle existe
    On Error Resume Next
    ActiveSheet.Shapes("cobaie").Delete
    On Error GoTo 0
    DoEvents
    Set shap = ActiveSheet.Shapes.AddShape(1, 0, 0, R.WidthPoint / z, R.HeightPoint / z)
    With shap
        .Name = "cobaie"
        .Fill.Transparency = 0.9
        .Fill.ForeColor.RGB = vbGreen
        .Line.Weight = 2
        .Line.ForeColor.RGB = vbRed
        .Line.Transparency = 0
        .ZOrder msoSendToBack
        .Left = 2
        .Width = .Width - .Line.Weight + _
                             (-4 * Abs(Not ActiveWindow.DisplayVerticalScrollBar) And Application.WindowState = xlMaximized)
        .Top = 2
        .Height = .Height - .Line.Weight
    End With
End Sub
demo1.gif
 

patricktoulon

XLDnaute Barbatruc
conclusion:
mon principe de trotti trotta avec le rangefrompoint me donne bien le bottom/right EXACT!!
Le reste n'est que de l'arrangement pour la shape(ou autres)

voilà on a fini
t' en a encore d'autres comme celle là @Dudu2
je cherche je trouve

edit
testé sur 2007 win 7 portable ok
je vais tester sur 2016 dans ma partition virtuelle
 

Dudu2

XLDnaute Barbatruc
N'empêche, on fait des découvertes à se casser les dents sur ces affichages.
Par exemple, j'ai constaté que le calcul des marges de UserForm était incorrect de 1 pixel.
 

Pièces jointes

  • ExactVisibleRangeSize.xlsm
    70.2 KB · Affichages: 1

patricktoulon

XLDnaute Barbatruc
re
1° problème dwm
2° echelle windows dpi ne correspond pas avec la réalité
3° les arrondis de calculs
4°le zoom d'excel qui est de 99.78% pour 100% chez moi
sans parler de son irrégularité selon le pourcentage je vous le prouve quand vous voulez
c'est du au fait que les calculs sont basé sur un ratio 4/3 (nos bon veux tubes cathodiques)qui on été ajustés au ratio 16/9 ou 16/10(écran actuels)
 

patricktoulon

XLDnaute Barbatruc
tiens regardez bien
je place une shape recouvrant parfaitement une plage de cellule
j'ai pis 2 boutons zoom+2 zoom-2 pour zoomer ou dézoomer de 2
je place un userform qui lui ne fait pas parti de la fenêtre excel il n'est donc pas impacté par le zoom
je le place juste au dessus de la shape
pour que vous voyez l'énormité je vais jusqu'a 142%(ce sera suffisamment assez gros pour que vous le voyez)
et je redescends à 140%
regardez l'énormité
demo1.gif
on voit clairement que le ration a changé
le zoom 142 de zoom plus que le width

Allez je rajoute un userform vous vérifier le bas

demo1.gif


si vous le voyez pas j'ai bien peur de ne rien pouvoir faire
parti de la comment voulez vous faire du générique autre qu'approximatif ?
 

Dudu2

XLDnaute Barbatruc
Bonjour les cadreurs de cadres et chercheurs de pixels,

En fait nul besoin de trotti trotta.
Les UsableWidth et UsableHeight répondent au besoin. Il faut juste savoir qu'ils incluent les Headings dont il faut alors retirer les dimensions lorsqu'ils sont présents.

De plus, avec cette méthode, la correction (chez moi) du RECT relatif à la Window est cohérent sur tous les points du RECT avec un + SM_CX/YBORDER, que ce soit en maximisé ou réduit, en échelle 100% ou 125%.
 

Pièces jointes

  • ExactVisibleRangeSize.xlsm
    72.5 KB · Affichages: 2
Dernière édition:

Dudu2

XLDnaute Barbatruc
Ce qui justifie mes différentes corrections en RECT relatif à la Window c'est qu'entre la méthode Trotti trotta et la méthode Usable, il y a des différences d'1 pixel dans les RECT absolus (sans correction) ci-dessous.

1733040147191.png
1733040026221.png
 
Dernière édition:

patricktoulon

XLDnaute Barbatruc
re
Bonjour @Dudu2
test du post 118
les userform ça va
par contre le rectangle
en mode full system ca va
si j’enlève simplement la scroll verticale
ça ne va plus
mon visible range se termine en colonne S
1733042325179.png



et quand je fait défiler pour aller voir on est entre 7 et 10 points trop grand
donc tes calculs sont faux ou les paramètre que tu utilise ne sont pas les bons

1733042235948.png



pour en revenir au trotti trota
cette méthode teste le point(x,y) dans rangefrompoint à l’écran
c'est le principe du getpixel en fait sauf que la on a un object retourné
si c'est pas nothing on est donc dedans
donc il ne peut pas y avoir d'erreur puisque je descend pixel par pixel et va a droite pixel par pixel
si un pixel x,y dans rangefrompoint me donne nothing c'est donc le pixel précédent
il n'y a même pas une erreur de 1 pixel possible
si après la shape ou les userforms ne sont pas bons c'est le calcul qui n'est pas bon
alors
soit les paramètres de calcul ne sont pas les bons et là je parle des constante SM_Xborder etc....
soit c'est la methode dans les calculs

alors oui après tes multiples versions on arrive a peu près en enlevant ceci ou cela
mais c'est les ceci ou cela que je remet en question
car ces ceci ou cela n'ont pas les même valeur c'est l'es uns et les autres
même si il y a des éléments constants valables pour toute versions
 

Statistiques des forums

Discussions
314 898
Messages
2 114 009
Membres
112 073
dernier inscrit
dimakhadra