Autres toutes versions tester le scrool avec la roulette sans passer par un hooking en addressof

[patricktoulon]

Bonjour a tous
la principal raison des crash excel quand on utilise le hooking de la souris pour avoir le mouse wheel(la roulette)
c'est que le looping avec le (CallnextHook)est asynchrone avec le captage du message de la souris
donc quand une erreur se produit(on va trop vite ou autre)
le looping lui continue parfois au moins une fois même en erreur
résultat comme on déplace le block type du message en mémoire ça crash

je vous propose de tester ceci
ici on va rester dans un do/loop vba classique et le message de la souris sera récupéré par un peekmessage
si il y a une erreur (du au message de la souris non conforme) normalement on a une erreur vba classique
et donc le do/loop est interrompu
donc pas de relance avec un message de la souris erroné donc pas de crash
Vous constaterez que j'augmente l'allocation de la mémoire aussi (64 bits double (longlong ou longPtr))(+2&)

d'autant plus que la dans cette démo je met tout dans le userform
ce qui n'est pas possible avec un code de hooking bien entendu
et ça peut avoir un avantage lorsque l'on veut distribuer un interface(userform) sans devoir l'accompagner de x modules

toujours pareil pour déterminer le rectangle je me sert de ma fonction perso du calendar que j'ai modifié pour ce besoins
donc testez et si ça fonctionne je ferais une ressource au propre

merci d'avance pour votre participation

j'en connais un qui vas ouvrir grand les yeux 🤣

Patrick

 

[patricktoulon]

résumé et conclusion pour les deux versions

version Iaccessible
avantage:
fonctionne sur toutes les configs Window/office testées a ce jour (32/64) bits
désavantage:
sur combobox obligé de se balader avec la souris dans la fenêtre child qui se développe(feuille et userform)pour enclencher le scroll
stop le pointeur quand on passe sur un autre object par exemple ici dans le control image dans le multipage

version WindowFromPoint
avantage
fonctionne très bien en 32 bits( prolonger les test pour le 64 bits)
les combobox sont scrollable des la fenêtre développée (pas besoins d'être sur la fenêtre child)
désavantage
le passage d'une fenêtre multipage a fenêtre userform peut etre problématique vu que c'est toujours thunderXDframe qui est renvoyé comme classe de fenêtre
le passage sur un control non injecté n’arrête pas le scroll dans les multipage ( je pense à @Valtraze)
avantages indéniable pour les deux
fini le hooking et les soucis de crash excel et au erreur critique du au hooking en vba réputé instable
au mieux l'erreur est gérée et passe le tour de do/loop suivant

 

[patricktoulon]

re
ha là tu m'intéresse @Rheeem c'est vrai que c'est simple comme raisonnement
ne pouvant pas tester il faudra le retour de @jurassic pork ou d'autres

 

[ChTi160]

Bonjour le Fil
Travail de longue haleine ! Lol
Y'aura t'il (mais sûrement ) un fichier récapitulatif des dernières évolutions ?
Merci encore aux contributeurs.
Jean marie

 

[patricktoulon]

et oui jean marie c'est ça un travail bien fait
il faut tout passer en revue pour vous fournir un truc bien solide
et en finir une bonne fois pour toute avec les api de hooking
et avoir ainsi des controls pouvant être scroller
ça n'a l'air de rien mais dans un applicatif ces petits trucs font la différence

et c'est vrai que je suis assez content du fait qu'il y est des participants a la discussion avec diverses configs
ce qui m'a permis d'avancer dans l'élaboration du code
sans parler du grand coup de main de @jurassic pork

 

[patricktoulon]

et pour tout vous dire je suis entrain de voir avec sendmessageA
voir si je peux pas carrément supprimer la sub scroller dans la version Iaccessible
grosso modo il y aura plus de code de déclaration que de fonction et macro

 

[jurassic pork]

re
ha là tu m'intéresse @Rheeem c'est vrai que c'est simple comme raisonnement
ne pouvant pas tester il faudra le retour de @jurassic pork ou d'autres

Je confirme que la fonction de Rheeem du post #165 sans CopyMemory fonctionne très bien.

 

[patricktoulon]

tiens @Rheeem si tu veux tester sur ton 64 bits ,la version rangefrompoint avec ta conversion

 

[patricktoulon]

re
et @Dudu2 on l a plus vu il est passé ou 🤣
j'ai peut etre une solution pour le scrollable de la combo directe dès le developpement de la child dans les userforms avec la version IAccessible+accRole

j'aimerais bien qu'il vienne moi dudu qu'il voit ce que propose @Rheeem
ça promet d'être intéressant

 

[Dudu2]

Bonsoir la liste,

Je suis toujours le sujet.
Tu parles du PointToLongLong de @Rheeem ? Oui, c'est bien c'est une autre façon de faire que le CopyMemory qui reste d'actualité.

J'ai passé pas mal de temps à faire une version qui traite les TextBox, mais ces foutues TexBox ne sont pas faciles à traiter car elles ne se comportent pas comme les autres Controls. A noter qu'en standard, quand on rentre dans une TextBox, elle se positionne à la fin.

J'ai imité ta méthode pour figer le Scroll de la feuille lorsqu'on Scroll un Control, peut-être cela réglera le problème que tu as eu de la listBox en double (?), ce truc vraiment très bizarre chez toi.

J'ai aussi essayé de trouver en vain le Handle de la Window DropDown de la ComboBox à partir de soit du Child de sa Window de base soit des Child Windows de l'application. Rien à faire ! La seule façon de le trouver c'est avec un GetWindowFromPoint(). J'aimerais bien avoir une solution qui ne dépende pas du curseur.

A titre d'info je vous passe ma version ListBox / ComboBox / TextBox (pas de Frame, Page, Image ici).
Çà marche en Excel 2016 / 32 bits. Pour l'instant je n'ai pas de 64 Bits car j'ai cramé mon Desktop à cause de ces nouvelles alimentations avec des broches à 6 ou 8 trous qui ne sont pas standards d'un PC à l'autre. Où sont les bonnes vieilles Molex ?!
Çà va me coûter une carte mère et son montage !

 

[patricktoulon]

re

bon
il y a toujours la double listbox chez moi

après je ne vois pas ce qu'apporte ton truc, tu fait la même chose que moi avec windowfrompoint mais en plus compliqué
j'ai cru voir aussi getwindowrect alors que tu travaille avec Iaccessible ???????????????????????
ou alors tu a laissé des declarations pour rien

le textbox c'est plus compliqué que ça on verra apres
il faut se concentrer sur la combo scrollable des le dropbuton click(developpée)
j'ai utilisé une vielle astuce qui consiste a faire deux test point(x,y) mais ca ne me plait pas c'est pas propre et fluide la sortie

edit :ha!!! j'ai eu une fermeture brutale d'excel

 

[Dudu2]

Encore cette double ListBox ? Vraiment étrange, inexplicable.
Sinon dans la dernière version que tu as publiée j'ai de temps à autres des sauts sur la feuille quand je passe sur les Controls.

 

[Dudu2]

après je ne vois pas ce qu'apporte ton truc tu fait la même chose que moi avec windowfrompoint mais en plus compliqué

Non, je ne fais pas la même chose que toi, c'est plus simple que ce que tu fais, et ce que ça apporte c'est mon plaisir.
J'utilise WindowFromAccessibleObject() (contrairement à toi) et WindowFromPoint() seulement pour la DropDown Window de la ComboBox.
D'ailleurs je n'ai toujours pas compris ta logique de boucle. Je n'arrive pas à décrypter le code.

 

[patricktoulon]

en tout cas si ce que propose Rheeem fonctionne en 64 je vire definitivement copymemory de l’équation

est ce que ça fonctionne chez toi si tu est en 64 bits 172
oui j'ai vu pour les sursaut de feuille
et j'ai trouvé pour la version rangefrompoint ça y est c'est propre

le sursaut c'est du au fait que je calle le scrollarea a la cellule topleftcell en dessous et quand cette cellule n'est pas visible ben le visible range s'adapte c'est tout
je crois que je vais le bloquer plutot au visible range -1-1

voila maintenant le croll est dispo pour les combobox dès qu'elle est developpée plus la peine d'aller se balader dans la child
voila reste plus qu'a bien tester sur 64 bits

 

[Dudu2]

Ok, et il faut que tu protège l'ESC lors du Scroll sinon c'est interruption directe. Fonctionnellement l'ESC peut servir à fermer le DropDown.

 

[Dudu2]

Autre petit souci dans ton code dont je crois avoir compris la logique de boucle ce qui m'a permis de mettre ça en évidence, car il ne suffit pas de tester la classe du parent pour considérer que c'est bon.
Je crois qu'il serait mieux de capter le Handle du Control au tout départ (GetWndowFromPoint) et tester si les GetWndowFromPoint suivant rendent le même Handle. C'est ce que je vais faire pour tester.