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

patricktoulon

XLDnaute Barbatruc
re
en 64 bits ça ne fonctionne pas c'est sur je peux te le confirmer tout de suite sans problème

je precise
uniquement pour les déclaration !!!!!!!!!!!!!!!!!!!!et constante nécessitant reconversion pour api en 64

dans l’exécution d'un code on s'en fou un long est un long un point c'est tout
 

patricktoulon

XLDnaute Barbatruc
j'entretiens rien du tout c'est un fait

et entre nous pour le handle de l'application pas besoins d'api

compatible 32/64 bits
pour l'application :
dim x as long
x= application.hwnd


pour une listbox ou frame ou combobox il existe une property peu utilisée et méconnue
exemple
x=Listbox1.[_GethWnd]
x=frame1.[_GethWnd]
 

patricktoulon

XLDnaute Barbatruc
re
d'ailleurs pour lever toute ambiguïté chez toi Dranreb

j'en veux pour preuve cette exemple d'utilisation de l'api user32 (au black sans declaration et compatible 32/64bits) utilisant une variable long!!! dans le code de la macro

VB:
'**********************************************************************************************
'      Ajouter les deux boutons manquants dans la barre de titre  à l'UserForm  et le mouse resizepar les angles et les cotés
'patricktoulon
'**********************************************************************************************

'EXEMPLE
Private Sub UserForm_Activate()
    trois_boutons
End Sub

Private Sub trois_boutons()
    Dim hwnd&'!!!!!!! c'est bien un long et non un longptr !!!!!!!!!!!!
    hwnd = ExecuteExcel4Macro("CALL(""user32"",""GetActiveWindow"",""JCC"")")         'api GetActiveWindow
    ExecuteExcel4Macro ("CALL(""user32"",""SetWindowLongA"",""JJJJJ""," & hwnd & ", " & -16 & ", " & &H94CF0080 & ")")     'api SetWindowLongA
End Sub
je n'entretien pas la confusion c'est un fait !!!
et tu peux tester ça fonctionne très bien en 64 comme en 32
;)
 

Dranreb

XLDnaute Barbatruc
Preuve supplémentaire que les handles sont restés As Long et qu'il n'y a donc pas lieu de les déclarer As LongPtr dans les instructions Declare.
 

patricktoulon

XLDnaute Barbatruc
RE
si pour les déclaration 64 c'est obligé !! sinon elles ne fonctionnent pas (j'ai testé)

après je ne dit pas que tout ce qui as long dans les déclarations doivent être as longptr en 64

UNIQUEMENT LES HANDLES OU ADRESSE APPELLE CA COMME TU VEUX

c'est ptrsafe qui est obligatoire en 64

MAIS dans la macro la variable peut rester "As long"

je pense l'avoir suffisamment démontré
;)

et pour éviter de perduré une "confusion"
Thierry GASPERMENT alias Arkham46 sur DVP
résume tout avec ce petit paragraphe
Capture.JPG
 

Dranreb

XLDnaute Barbatruc
Comme dit, j'ai des doutes quand aux handles, pour les raisons que j'ai invoquées au poste #75. Ce n'est pas du tout la même chose qu'une adresse. C'est un Indice dans une table d'adresses maintenue par Windows. En tout cas ça doit être cohérent dans tout le code, pas seulement dans les Declare. Si un argument d'une Sub y a été déclaré même à tort As LongPtr, alors dans tout le code même en dehors du Declare, une variable spécifié en guise de ce paramètre devra aussi être déclarée As LongPtr.
 
Dernière édition:

patricktoulon

XLDnaute Barbatruc
c'est comme tu veux
je comprends aussi ton point de vue sur cette question qui n'est pas dénuer de sens
sauf quand on fait la différence entre getDC ET getHANDLE ;)
 

patricktoulon

XLDnaute Barbatruc
re
je reconnais m’être casser la tète au début long/longlong/longptr
kézakoca !!!! :D:D
mais si tu respecte ce que le petit paragraphe dit ben tu n'as jamais de soucis
 

Dranreb

XLDnaute Barbatruc
Je suppose que les LongPtr mis à tort dans les Declare ne gêne pas le fonctionnement. Ça n'implique après tout que deux conditions: 1) — seuls les 4 octets de poids faibles sont utilisé (ils sont en tête toujours), 2) — Dans les listes de paramètres les argument sont tous rangés à des adresses entières de 8 octets. En somme ça ne ferait qu'obliger inutilement à déclarer ailleurs aussi As LongPtr les variables qui y sont précisées en tant qu'arguments.
 

patricktoulon

XLDnaute Barbatruc
ça ne ferait qu'obliger inutilement à déclarer ailleurs aussi As LongPtr les variables qui y sont précisées en tant qu'arguments.

tente tu verra par toi même ?

et puis x octés + y octés+ z octés dans un programme pas multithread et qui exécute son code linéairement comme vba le fait......... ben ça compte ;)
 

Dudu2

XLDnaute Barbatruc
Bonjour,

En attendant la déconfination (et je l'attends avant la déconfiture !) je voudrais compléter mes investigations du message #61 en postant un essai de Scroll sur ListBox dont la sortie est aussi déclenchée par un positionnement souris hors la zone du Control sous Scroll. C'était une des remarques de ce message spécifiquement pour les ListBoxes. Ça pourrait s'appliquer aussi à une ComboBox mais la méthode postée dans ce message #61 est assez bien sécurisée pour les ComboBoxes.

Ça implique l'utilisation d'un module développé pour l'occasion et inclut dans le code (Module_PixelsToPointsToPixelsV0) qui peut trouver plus souvent une utilité certaine dans les conversions Pixels / Points d'objets divers et dont l'une des fonctions MouseIsOverObject(Object As Object) est utilisée pour savoir si le curseur de la souris est sur un objet donné ou pas.
De petites adaptations ont été faites aussi au module de Hook (Module_HookMouseV0) pour utiliser cette fonction.

Edit 08/05/2020: Fichiers mis à jour pour simplification des adaptations et généralisation du Module_HookMouseV0
Edit 31/05/2020: Fichiers mis à jour pour déclaration du plHooking en LongPtr pour compatibilité 64 bits.
 

Pièces jointes

  • VBA Scroll Souris en ComboBox V0.xlsm
    43.8 KB · Affichages: 16
  • VBA Scroll Souris en ListBox V0.xlsm
    64.4 KB · Affichages: 8
Dernière édition:

Dudu2

XLDnaute Barbatruc
J'ai fait quelques modifs dans le fichier ci-dessus pour rendre le module de Hook Mouse généraliste, que la référence à la fonction MouseIsOverObject() existe ou pas.

En VBA on ne peut 3 x hélas pas définir des constantes préprocesseur visibles hors du module où elles sont définies.
Dans un module B, la référence à une fonction définie dans module A ne peut donc être "couverte" par un #If sur une #Constante de ce module A.
Le seul stratagème que j'ai trouvé pour contourner ce problème et ne pas avoir une erreur du compilateur/ éditeur de liens (Sub ou Fonction non définie) est, dans le module B, de pas appeler directement la ou les fonctions du module A, ne sachant si ce module A fait partie du Projet VBA, mais de les appeler via un Application.Run dont la 1ère exécution en erreur (ou pas) définit l'absence (ou la présence) de la ou des fonctions du module A.

Cet artifice est sans doute un peu moins efficace qu'un appel direct car la référence à la fonction passée en String dans l'Application.Run doit être recherchée dans les tables internes du compilateur.
 
Dernière édition:

Dranreb

XLDnaute Barbatruc
Bonsoir
Je n'ai guère exploré le sujet, mais avec un clic droit sur le VBAProject, Propriétés de VBAProject, page Général, on a une box "Arguments de compilation conditionnelles" qui pourrait permettre d'en définir appliquées à tout le projet. Peut être …
 

Statistiques des forums

Discussions
312 069
Messages
2 085 041
Membres
102 764
dernier inscrit
nestu