XL 2016 VBA - Déclarations des fonctions l'API Windows

[Dudu2]

Bonjour,

Je voudrais avoir la confirmation de la manière de déclarer les fonctions de l'API Windows selon les constantes de compilation prédéfinies. Avec l'exemple de GetParent().

J'ai vu ce type de déclaration...

#If VBA7 Then
    #If Win64 Then
        Declare PtrSafe Function GetParent Lib "user32" (ByVal hwnd As LongPtr) As LongPtr
    #Else
        Declare PtrSafe Function GetParent Lib "user32" (ByVal hwnd As Long) As Long
    #End If
#Else
    Declare Function GetParent Lib "user32" (ByVal hwnd As Long) As Long
#End If

Mais la doc Windows dit:

Les variables LongPtr (long integer sur les systèmes 32 bits, longLong integer sur les systèmes 64 bits)

Donc ceci devrait suffire non ?

#If VBA7 Then
    Declare PtrSafe Function GetParent Lib "user32" (ByVal hwnd As LongPtr) As LongPtr
#Else
    Declare Function GetParent Lib "user32" (ByVal hwnd As Long) As Long
#End If

D'autre part, question subsidiaire, dans cette page par ailleurs très utile, je vois ça:

#If Win64 Then
    Declare PtrSafe Function GetWindowLongPtr Lib "user32" Alias "GetWindowLongPtrA" (ByVal hwnd As LongPtr, ByVal nIndex As Long) As LongPtr
#Else
    Declare PtrSafe Function GetWindowLongPtr Lib "user32" Alias "GetWindowLongA" (ByVal hwnd As LongPtr, ByVal nIndex As Long) As LongPtr
#End If

Qu'est-ce qui est la "vraie" référence à la fonction ? GetWindowLongPtr ou GetWindowLongPtrA / GetWindowLongA?


Merci par avance.

 

[Staple1600]

Re

@Dudu2
Le test a echoué
Error Monsignor

Sur
'Get handle to userform
hWndForm = GetActiveWindow

Erreur de compilation:
Incompatibilité de type

 

[Dudu2]

'Get handle to userform
hWndForm = GetActiveWindow

Et oui, normal, c'est mal déclaré en Long dans ma fonction !

 

[patricktoulon]

re
ben tu a regarder le code en diagonal alors
j'ai mis les lignes du #VBA6 dans le #IfVBA7
en fait il n'y a que le VBA6 de déclaré et comme tu le dis ça fonctionne
donc je le redis pour VBA7 c'est vb6 c'est pour win64 que ptrsafe compte et le type de variable

donc les declaration ne devrait etre faite que sur ça

#if win64
ptrsafe et longptr(pour les handle(hwnd) et contexte(hdc)
#else
VB6 et c'est tout
#endif

à quelques exceptions près avec GDI par exemple mais là encore c'est selon le system installé ainsi que ces mise a jours car 2 systems identiques avec le même office même version auront un comportement différent

j'ajouterais que pour developper en 64 bits ,vaudrait mieux avoir 64 bits
là tu pars a la chasse au DAHU

 

[Staple1600]

@Dudu2 (au fait bonjour @patricktoulon)

Donc tu me fais faire un test en sachant que je vais faire tousser mon petit VBE qui est innocent

NB: @Dudu2, tu peux juste republier les bonnes déclarations API pour 64 bits
que je reteste de nouveau.

 

[Dudu2]

Le Dahu j'ai plus de chance de le trouver dans le Mercantour que sur le Mont Faron.
Je reviens sur mes LongPtr de partout, je crois pas que ce soit une bonne idée. Je vais me conformer à ce que je trouve ici mais j'abandonne les déclarations VBA6 pour simplifier.

@Dudu2, tu peux juste republier les bonnes déclarations API pour 64 bits

C'était pas les déclarations API mais les déclarations de variables. Car il faut que les variables aussi soient LongPtr.
Edit: Faut aussi laisser les déclarations de Constantes sans type (en Variant) pour ne pas avoir à gérer leurs types.
J'ai revu le code, @Staple1600, je te sollicite pour un nouveau test. Merci.

 

[Staple1600]

Re

@Dudu2
Test oK

PS: D'habitude, on ne met pas les déclarations API dans un module standard (en public) ?
Ou plutôt n'est-ce pas l'usage communément admis ?

 

[Dudu2]

@Staple1600,
Merci pour ta confirmation !

PS: D'habitude, on ne met pas les déclarations API dans un module standard (en public) ?

Je sais pas trop...
Perso je les déclare Private dans chacun des modules concernés pour rendre les modules autonomes.

 

[patricktoulon]

re
pour info
les déclarations qui commencent par "Declare...." sont d'office en public
d'ailleurs pour vous en convaincre essayez donc de les déclarer dans un usef sans private

 

[Dudu2]

d'ailleurs pour vous en convaincre essayez donc de les déclarer dans un usef sans private

Absolument, Private obligatoire en UserForm !

@Staple1600, un dernier pour la route, puis j'essaierai d'installer Office en 64 bits sur mon Laptop.

 

[Staple1600]

Re

@Dudu2
Test OK

[avis personnel]
Avec mon principe K.I.S.S tatoué sur la fesse gauche, ceci suffira

Sub test()
MsgBox "Ceci est une information", vbInformation, "Titre"
End Sub

Au plus simple, toujours et encore

PS: Avec l'avantage qu'avec le VBA natif, on minimise les problèmes dus aux versions
[/avis personnel]

 

[Dudu2]

Au plus simple, toujours et encore

Au plus simple n'est pas forcément au plus juste. Va mettre des libellés custom dans les boutons d'un MsgBox !
Si je l'ai fait c'est que j'en avais besoin, c'est aussi simple que ça.
D'ailleurs je n'ai pas été ni le seul ni le premier, le célèbre mDF l'a fait il y a bien longtemps:

MsgBox personnalisées (API) - Tutoriels & Astuces Excel > L'API Windows - Tutoriels : myDearFriend! Excel Pages

Une MsgBox avec boutons personnalisés, est ce possible La MsgBox est une fonction importante de VBA, mais nous avons tous constaté un jour ou l'autre qu'elle souffre d'un gros manque en terme de personnalisation qui d'entre nous n'a jamais souhaité pouvoir se servir d'autre chose que des 7...

www.mdf-xlpages.com

Il me semble même que le célèbre @patricktoulon qui plussoit à la simplicité s'y est collé .

 

[Staple1600]

Re

@Dudu2
J'avais bien précisé [avis personnel]
Signé
un fervent adepte du KISS, qui est happy sans API

PS: mon avis personnel n'était pas une critique à ton endroit mais juste mon avis.
Dans le cas, d'un MsgBox classique ou personnalisé, ce qui compte c'est le message qui s'affiche non ?
Et pour ma part, je préfère utiliser une seule ligne de code pour ce faire.

 

[patricktoulon]

oui pour moi je m'y suis collé
mais entre nous ce genre de chose je le fait pour m'amuser
sauf si c'est indispensable dans mes app j'utilise le moins d'api possible
(et encore pour plus me faire Ch... j’utilise executeExcel4macro)
comme ca je n'ai pas ce soucis de péter dans le safe ou de faire des longprout

ma devise
le moins de code possible(malgré un nombre de fonction perso gigantesque a mon actif
le moins de MFC possible(terriblement lourde sur les versione office récentes )
le moins d'apis possible et uniquement executeExcel4macro

et si j'en ai vraiment besoins je me fait une passerelle(complément)en VB6 et que je propose d'installer
afin de ne pas bouffer la mémoire alloué a excel avec des module interminables ou une chatte ne retrouverais pas ses chattons

tu y viendras toi aussi
pour le moment la chose t'amuse et tu a bien raison et ça forge le développeur

 

[Dudu2]

PS: mon avis personnel n'était pas une critique à ton endroit

Mais je sais bien @Staple1600, on discute

.

pour le moment la chose t'amuse et tu a bien raison et ça forge le développeur

Oui, c'est sûr, mais parfois on est bien content de proposer des boutons libellés aux différentes options / choix à proposer à l'utilisateur. Et je te garantis que ça m'est très utile assez souvent. Sinon on fait quoi ? Un InputBox avec des choix de 1 à n construits en String et le choix à saisir ? Ok, ça peut se faire...

Enfin, je suis assez content de cette discussion qui m'a permis et d'autres aussi j'espère de clarifier autant que possible ces histoires de PtrSafe, LongPtr, VBA6/VBA7, Win32/Win64. Maintenant je sais ce que je dois faire et en plus je le comprends, c'est déjà pas si mal

.

 

[Staple1600]

Re

@patricktoulon
Ce quoi à j'ajouterai (là encore mon avis et ce n'est que mon avis)
-le moins d'Excel possible
(qui est d'abord un tableur, pas un logiciel de programmation)
=> il est pas dans la liste