Mouse Wheel Hook (faire défiler le contenu d'une combobox/listbox avec la roulette)
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.
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.
codekabinett.com
ns4business.com.br
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.
Vue d’ensemble de Visual Basic pour Applications 64 bits
Rubrique de référence sur Office VBA
docs.microsoft.com
Declaring API functions for 64 bit Office (and Mac Office)
JKP Application Development Services, Microsoft Office Application Development
www.jkp-ads.com
32 Bit And 64 Bit Api Declarations For Vba Developers - Xlttn.com
A comprehensive guide for VBA developers on 32 Bit and 64 Bit API declarations. Learn how to get started, best practices, tips and tricks. Explore more today.
xlttn.com
Windows API declarations in VBA for 64-bit
How to convert your API Declarations to 64-bit. - Common myths debunked, key factors explained!
codekabinett.com
Declaring API Functions In 64 Bit Office
ns4business.com.br
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.
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.
La difficulté restante est d'identifier les paramètres ou valeurs de retour des fonctions de l'API candidates au LongPtr.
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.
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:
L'affaire du wParam et du lParam est assez mystérieuse.
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:
| WPARAM | A message parameter. This type is declared in WinDef.h as follows: typedef UINT_PTR WPARAM; |
| LPARAM | A 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.
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
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.
| BOOL | A Boolean variable (should be TRUE or FALSE). This type is declared in WinDef.h as follows: typedef int BOOL; |
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.
vérifier pour moi
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 !
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
et Merci
(2 en fait).
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 !
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
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.
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.
Dudu2
XLDnaute Barbatruc
Ah dommage !
Merci Gallagh Chatvirgo pour ton retour.
Même si tu as un double moniteur, c'est confirmé sur PC Astuces par ReineClaude que ça plante aussi en mono-moniteur en 64 bits.
Si chiendich a l'occasion de vérifier en Office 64 bits il saura identifier la problème j'espère.
Merci Gallagh Chatvirgo pour ton retour.
Même si tu as un double moniteur, c'est confirmé sur PC Astuces par ReineClaude que ça plante aussi en mono-moniteur en 64 bits.
Si chiendich a l'occasion de vérifier en Office 64 bits il saura identifier la problème j'espère.
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
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
J'utilise win10, office 2013 32 bits. ne devrait pas être en mesure de tester.
Dudu2
XLDnaute Barbatruc
Bonjour les scrollers,
@chiendich,
@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.
@chiendich,
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:
