C'est quand meme un peu plus puissant qu'une procedure car ça interviens avant qu'un evenement ne s'effectue, c'est pas ça ???
En fait le callback te permet d'intercepter l'évènement avant qu'elle n'arrive dans la boucle d'évènement de la fenêtre.
Mais quel est l'intérêt puisque de toute façon le message arrivera dans notre boucle d'évènement?
Eh bien la boucle d'évènement de Pure ne permet pas de recevoir tous les messages, si tu envoie un message par la commande Sendmessage_(..), tu ne la recevras pas alors qu'avec un callback tu es sûr de récupérer tous les évènements et ça reste plus facile de travailler avec un callback.
Donc d'apres toi, si je fais un windowevent #Mouse_MOVE c'est exactement comme si je met dans la callback case #WM_MouseMove ou bien une sera toujour executée avant l'autre ????
Oui c'est pareil; ce sera toujours le callback qui recevra le message en premier; en traitant ce message et en renvoyant un procedurereturn 0, tu cloture le traitement du message et ta boucle ne le recevras pas sinon le message seras traité deux fois, suivant les besoins ça peut être l'un ou l'autre.
J'ai découvert un de tes posts précédent ayant pour titre" Callback <--> Subclassing"
J'ai toujours pensé qu'un setwindowcalback effectuait un subclassing mais je peux me tromper, mais bon dans ce cas là ça revient au même.
Pure basic ne permet de subclasser que des fenêtres, mais ce qui est intéressant c'est surtout de pouvoir subclasser les controles (gadget).
Car un controle, c'est une fenêtre qui a elle aussi une boucle d'évènement et qui régit son comportement et à la différence d'une fenêtre tu n'as pas accès à celle-ci d'où l'intérêt du subclassing pour modifier le comportement d'un controle.
Regarde cet exemple, je subclasse le StringGadget 0 pour que lorsque je tape Enter je passe au gadget suivant:
Code : Tout sélectionner
Procedure NouvelleProc( hWnd, Msg, wParam, lParam)
;Ici on récupère l'adresse d'origine de la procédure grâce à la
;chaine qui l'identifie: "OriginProc" et le handle de la fenêtre
;voir la fonction SetProp.
OriginProc.l= GetProp_(hWnd, "OriginProc")
Select Msg
Case #wm_char
If wParam=$0D
;Simulation de la touche Tab
keybd_event_($09, 0, 0, 0)
keybd_event_($09, 0, #KEYEVENTF_KEYUP, 0)
ProcedureReturn 0
EndIf
EndSelect
;On renvoie tous les autres évènements à la procédure d'origine.
ProcedureReturn CallWindowProc_(OriginProc,hWnd,Msg,wParam,lParam)
EndProcedure
If OpenWindow(0,0,0,322,275,#PB_Window_SystemMenu|#PB_Window_ScreenCentered,"StringGadget Flags") And CreateGadgetList(WindowID(0))
StringGadget(0,8, 10,306,20,"Normal StringGadget...")
StringGadget(1,8, 35,306,20,"1234567",#PB_String_Numeric)
StringGadget(2,8, 60,306,20,"Readonly StringGadget",#PB_String_ReadOnly)
;Avec cette fonction, on récupère l'adresse d'origine de la procédure
;pour ensuite la restituer, une fois le traitement terminé.
OriginProc = SetWindowLong_(GadgetID(0), #GWL_WNDPROC, @NouvelleProc())
;Cette fonction est très utile car elle permet d'associer une nouvelle donnée
;à n'importe quelles fenêtres crées en utlisant une chaine de caractère pour
;l'identification; ça évite d'utiliser une valeur globale.
;Ici on associe la valeur OriginProc identifiée par la chaine "OriginProc"
;au StringGadget
SetProp_(GadgetID(0), "OriginProc", OriginProc)
Repeat
EventID = WaitWindowEvent()
Select EventID
Case #PB_EventGadget
Select EventGadgetID()
Case 0
Debug "Normal StringGadget"
EndSelect
Case #WM_CLOSE
;Supprimer avant fermeture du programme la donnée associée à la fenêtre.
RemoveProp_(GadgetID(0),"OriginProc")
Quit=1
EndSelect
Until Quit=1
EndIf
, j'aimerais savoir si on peut en faire autant qu'un curé peut en bénir 