Mouse Wheel Hook (faire défiler le contenu d'une combobox/listbox avec la roulette)

  • Initiateur de la discussion Compte Supprimé 979
  • Date de début

zoumi

XLDnaute Nouveau
En effet, ça plante à cause de plusieurs problèmes de compatibilité entre Long et LongPtr.
Faut aussi que je revoie toutes les déclarations des fonctions de l'API Windows et le step de scroll sous 64 bits qui semble plus sensible comme l'a indiqué patricktoulon.
Ceci dit, ces fonctions de Hook récupérées sur le Net et modifiées sont assez absconses et à vérifier sur 64 bits dont hélas je n'ai pas l'environnement pour tester.


Tu peux m'envoyer tes fichier pour tester.
 

Dranreb

XLDnaute Barbatruc
Bonjour.
L'incompatibilité de type signalée au #104 semble due à un typage en LongPtr au lieu de Long de l'argument wParam dans la Declare Function CallNextHookEx
Au vu des constantes nommées qu'il peut prendre, je me demande s'il ne devrait pas être Integer d'ailleurs, d'autant que le 'w' devant signifie probablement 'word' donc 16 bits.
 
Dernière édition:

Dudu2

XLDnaute Barbatruc
Bonjour Bernard,
C'est la difficulté. Déclarer pour 64 bits (sans pouvoir le tester en plus !).
J'essaie de comprendre à partir de divers sites (ex ci-dessous) VBA7 vs non VBA7, Win64 vs Win32 pour PtrSafe et Long / LongPtr et pour l'instant je j'essaie seulement de comprendre. Et ensuite j'essaierai de résumer.
 

Dudu2

XLDnaute Barbatruc
En fait tout est dit dans https://docs.microsoft.com/fr-fr/of...64-bit-visual-basic-for-applications-overview.
La difficulté restante est d'identifier les paramètres ou valeurs de retour des fonctions de l'API candidates au LongPtr.
Les marqueurs et descripteurs dans des environnements 64 bits sont en 8 octets 64 bits
Comment identifier un "marqueur" ou un "descripteur" ? That is THE question !
Si un Handle est un candidat certain, pour d'autres types de données qu'on trouve dans la Doc MS (en C++) ce n'est pas du tout évident.
Alors il faut peut-être regarder les propositions diverses trouvées sur des sites.
 

Dudu2

XLDnaute Barbatruc
Concernant les Types référencés dans la Doc MS C++ il faut se référer à la page https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types.
L'affaire du wParam et du lParam est assez mystérieuse.
L'incompatibilité de type signalée au #104 semble due à un typage en LongPtr au lieu de Long de l'argument wParam dans la Declare Function CallNextHookEx
Merci, j'ai corrigé.
Pour VBA7 (donc 32 bits ou 64 bits) je vois souvent: ByVal wParam As LongPtr, lParam As Any (donc lParam Byref ?)

Mais je ne sais pas faire le lien avec ça:
WPARAMA message parameter.
This type is declared in WinDef.h as follows:
typedef UINT_PTR WPARAM;

LPARAMA message parameter.
This type is declared in WinDef.h as follows:
typedef LONG_PTR LPARAM;
 
Dernière édition:

Dranreb

XLDnaute Barbatruc
En tout cas l'erreur venait de ce que son type LongPtr annoncé à tort ou a raison dans l'instruction Declare n'était pas celui de la variable transmise.
Je disais juste en plus que même homogénéiser partout As Long me paraissait trop pour une variable testée à &H200 ou &H20A.
 

Dranreb

XLDnaute Barbatruc
S'il est si difficile de s'y retrouver quant au typage nécessaires pour les handles, c'est probablement parce que les deux existent. Windows est en effet certainement capable, sur demande d'un programme d'allouer plus de 2147483647 zones de mémoires différentes identifiées par des handles sur 64bits. Mais il n'y a pas de raison que les handles des objet Windows eux mêmes soient sur 64bits car il ne saurait y avoir autant de fenêtres, de programmes ou de périphériques etc. J'ai déjà lu, je ne sais plus où, que si on les transmettait quand même As LongPtr seule les 4 octets de poids faibles était utilisés. Seules les adresses doivent à coup sûr toujours être sur 64bits.
 

Dudu2

XLDnaute Barbatruc
Je disais juste en plus que même homogénéiser partout As Long me paraissait trop pour une variable testée à &H200 ou &H20A.
Oui, j'avais vu ta remarque. Mais on ne trouve pas de paramètres définis en 16 bits (Short en c++ si mes souvenirs ...). Et j'ai vu ces constantes définies en Long dans des exemples de code.
D'ailleurs, dans la même veine des fonctions indiquées comme retournant le type BOOL sont traduite en retour Long.

BOOLA Boolean variable (should be TRUE or FALSE).
This type is declared in WinDef.h as follows:
typedef int BOOL;

J'ai déjà lu, je ne sais plus où, que si on les transmettait quand même As LongPtr seule les 4 octets de poids faibles était utilisés.
N'était-ce pas dans une discussion avec patricktoulon où j'ai vu que ce sujet était abordé ? Je réalise bien que 64 bits c'est gigantesque et suis aussi étonné que ce soit nécessaire aux pointeurs et handles. Mais c'est comme ça que MS recommande de les représenter, d'où ces problèmes.
 

Dudu2

XLDnaute Barbatruc
@chiendich,
Ton fichier va devenir la référence en la matière, traitant tous les types de Controls indistinctement quelque soit leur nombre sans qu'on ait rien à faire de particulier pour chacun d'eux. C'est très très fort !
1599905777093.gif
1599905919455.gif
1599905921339.gif

Bien au dessus de mes modestes capacités de compréhension, d'autant que tu es plus qu'économe en commentaires, mais au fond est-ce bien important, car il suffit d'utiliser le module prêt à l'emploi.
Je n'ai qu'un mot Bravo
1599906143615.gif
et Merci
1599906386861.gif
(2 en fait).
 

Chatvirgo

XLDnaute Nouveau
Salut,
Chez moi, ca ne marche pas.
Je suis avec Excel 2019 en 64 bits, et bien sûr W10.
Bizarrement, l'Userform s'affiche sur mon second moniteur, et non sur le moniteur principal.
Dés que je point l'Userform avec la souris, Excel collapse immédiatement, sans aucun message d'erreur préalable.
Tant que je n'ai aps pointé l'Userform, tout av bien, je peux faire tout ce que je veux sur Excel, ... sauf pointer l'Userform.
 

patricktoulon

XLDnaute Barbatruc
bonsoir a tous
chez moi aussi ça fonctionne pas le model de @chiendich
je suis sur excel 2013 32 avec W7 64
essayez celui là
le simple survol sur le control lui attribut le scroll avec la molette
sauf les combo c'est le dropdown qui leur attribu la molette

dans les démos le simple survol d'un control a l'autre arrete la mollette du précédent et l'applique a celui sur le quel le curseur est
 

Pièces jointes

  • molette souris pour listebox2 et frame combobox .xlsm
    53.2 KB · Affichages: 9

Dudu2

XLDnaute Barbatruc
Bonjour les scrollers,
@chiendich,
J'utilise win10, office 2013 32 bits. ne devrait pas être en mesure de tester.
On attendra donc que tu aies l'occasion de quand même vérifier sur un Office 64 bits.

@patricktoulon,
En interceptant les évènements, sûr ça marche en 32 et 64 bits.
Il y a juste une faiblesse dans ces évènements c'est le Private Sub UserForm_MouseMove, car si on passe vite de la ListBox à l'extérieur du UserForm, cet évènement ne se déclenche pas et on reste en Scroll ListBox (ou autre Control). D'autre part cela implique qu'on soit dans le cadre d'un UserForm.

La détection de la position de la souris à chacun de ses mouvements par rapport aux Controls est imparable et, dans le code de chiendich plus encore que dans le mien, d'une mise en œuvre simplissime. Mais 64 bits nous em... et, sur une base programmatique correcte en 32 bits, se plante lamentablement.

Edit: J'ajoute que le fichier de chiendich, fonctionne parfaitement sur mon Laptop en Excel Pro 2010 32 bits sous Windows 8.1 64 bits et aussi sur mon Desktop en Excel Pro 2016 32 bits sous Windows 7 64 bits.
 
Dernière édition: