Event management, EventType()

[srod]

I can answer your first question re: the editor gadget.

The default for Windows rich edit controls (editor gadgets) is NOT to send notification of such 'change' events to the parent window.

To enable this you need to set the 'event mask' as shown below:

Code: Select all

If OpenWindow(0, 0, 0, 322, 150, "EditorGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered) And CreateGadgetList(WindowID(0)) 
    EditorGadget(0, 8, 8, 306, 133) 
;Add the following line to enable the editor gadget to send #EN_CHANGE notifications.
    SendMessage_(GadgetID(0), #EM_SETEVENTMASK, 0, SendMessage_(GadgetID(0), #EM_GETEVENTMASK, 0,0)|#ENM_CHANGE)
    
    For a = 0 To 5 
      AddGadgetItem(0, a, "Line "+Str(a)) 
    Next 

  Repeat
    Event = WaitWindowEvent()
    Select EventType()
      Case #PB_EventType_Change 
        Debug 1    
    EndSelect
  Until Event = #PB_Event_CloseWindow

End
EndIf 

Incidentally, the help file doesn't list EditorGadgets as being able to work with EventType() !

You must remember that Windows can send literally thousands of different kinds of message and Purebasic can't really hope to sift through them all; it'd be a nightmare! EventType() is there to make our lives a little easier when dealing with gadgets and their many possible events.

Beyond this, if a little 'fine tuning' is required then we are generally looking at using a callback.

As for EventWParam(), my advice - don't use it! If you consider using this, then I would go straight for a callback.

[mdp]

Many thanks, SRod

You example suggests this:
is it correct to say that they are all 'messages' (where 'message' is perhaps 'everything you can receive with a GetMessage_() on WinOS'), and that BP "makes some order" by assigning some to WindowEvent(), some to EventType(), some to GadgetEvent() etc.?

About getting the event parameters:

As for EventWParam(), my advice - don't use it!

Could you explain when/why?
For instance:

Code: Select all

Select EvID
   Case #WM_MOUSEWHEEL
      If wParam>0 : DoThis() :Else: DoThat() : EndIf 

seems (at least) to work quite well, so could you point to a "troublesome" use of EventWParam()?

[srod]

I wouldn't say that it is necessarily troublesome, but there has been some discussion around the use of EventWParam() etc. At one point, there was a suggestion that its use was to be deprecated, after all it is for Windows only and PB is striving for cross platform compatability. Personally, I keep away from it.

You example suggests this:
is it correct to say that they are all 'messages' (where 'message' is perhaps 'everything you can receive with a GetMessage_() on WinOS'), and that BP "makes some order" by assigning some to WindowEvent(), some to EventType(), some to GadgetEvent() etc.?

Not exactly true.

In 'classic' windows programming you would set up a message loop in which GetMessage_() is used to pull messages from the application's message queue and despatch them to the underlying Window procedure. PB's WaitWindowEvent_() will be doing exactly this.
The window procedure will then determine the type of message despatched and which control was responsible etc.

Of course this is all going on behind the scenes (mostly) in our PB programs. When we use the GadgetEvent() function, we are not pulling more messages from the queue, but simply asking Purebasic to provide us with extra information which it has already gleened within the window procedure sitting behind our own code.

Similarly with EventType(), no more messages are retrieved. PB is simply providing us with extra information; e.g. whether the last message pulled was a 'mouse' message or some kind of 'change' message to indicate that some gadget has had its data changed in some way.

In more 'traditional' windows programs we would have to determine all this information ourselves; some of which is easy to determine, some not so easy! Some of this information comes directly from the message, e.g. #WM_LBUTTONDOWN is a mouse left click. Other information can only be gained by delving into various structures supplied by Windows when calling the underlying window procedures etc.

It's all good stuff!