Multiple window problem

[Demivec]

I think I posted earlier, can these non official events be prevented from reaching the message loop in my program? Or is there a way of finding whether it is an official PB event so it can be discarded in my message loop before an attempt to find on which window the event occurred?

You simply process the PureBasic events and leave the rest to fend for themselves.

Here's an extensive and noisy example to show what is handled by PureBasic's message loop. I made the example to use as a reference for myself and I hope it is useful in answering your question as well. It is possible I may have made overlooked something but it was created with reference to the documentation. It makes an effort in the source code to show how various events are generated and what information is available to handle them.

In general everything is handled with Select/Case statements. At the very end is a 'default' case. The events that end up there are ones created using PostEvent(), the 'no event' (i.e. #Null), and events that aren't handled by PureBasic. So after you filter out any PostEvent() messages the rest you can ignore or properly handle by using SetWindowCallback().

Incidentally, if the WindowCallback is used, it would handle the specific OS messages and then pass control to the PureBasic message loop to process the rest. IMHO this means that the PureBasic message loop is not the proper place to handle OS event messages (at least not in the current version of PureBasic) if you are going to handle them at all.

Code: Select all

;Author: Demivec
;Date: 10/20/2015
;Written for: PureBasic v5.40 LTS
;General example of a classic event message loop.
;
;Using BindEvent(), BindGadgetEvent(), BindMenuEvent() are powerful alternatives to
;processing events with through the event loop.  There is also the use of SetWindowCallback()
;for handling all events generated by the OS that may or may not be handled through
;PureBasic's own message handling functions.


;This code only includes a single window.  You would typically place your windows, gadgets,
;and so forth here before the event loop.
OpenWindow(0, 0, 0, 600, 220, "MainWindow", #PB_Window_SystemMenu)


Define event, quit

Repeat  
  
  Repeat
    event = WindowEvent() ;or WaitWindowEvent() 
    Select event
      Case #PB_Event_Menu
    ;     Select EventMenu()
    ;       Case 0  ;Customize to handle specific menu numbers (or toolbar or keyboard shortcuts)
    ;       Default
            Debug "Menu: " + EventMenu() + ", window: " + EventWindow()
    ;     EndSelect
        
      Case #PB_Event_Gadget
    ;     Select EventGadget()
    ;       Case 0  ;Customize to handle specific gadget numbers.
    ;       Default
            ;Events are neither reported nor handled by every gadget type,
            ;refer to documentation for specific gadget type for further info.
            ;The CanvasGadget(), WebGadget() and OpenGLGadget() each also support a special set of events.
            Debug "Gadget: " + EventGadget() + ", type: " + EventType() + ", window: " + EventWindow()
    ;     EndSelect
        
      Case #PB_Event_SysTray 
        Select EventGadget()
          Case 0  ;Customize to handle specific system tray icon numbers.
          Default
            Debug "SysTrayIcon: " + EventGadget() + ", type: " + EventType()
        EndSelect
        
      Case #PB_Event_Timer    
    ;     Select EventTimer()
    ;       Case 0  ;Customize to handle specific system tray icon numbers.
    ;       Default
            Debug "Timer: " + EventTimer() + ", window: " + EventWindow()
    ;     EndSelect
        
      Case #PB_Event_WindowDrop  
    ;     Select EventWindow()
    ;       Case 0  ;Customize to handle specific windows as drop targets.
    ;       Default
            Debug "Drop onto Window : " + EventWindow() + ", type: " + EventDropType() + ", action: " + EventDropAction()
            ;Further functions to handle the event may include:
            ; EventDropText(), EventDropImage(), EventDropFiles(), EventDropPrivate(),
            ; EventDropBuffer(), EventDropSize(), EventDropX(), EventDropY()
    ;     EndSelect
        
      Case #PB_Event_GadgetDrop
    ;     Select EventGadget()
    ;       Case 0  ;Customize to handle specific gadgets as drop targets.
    ;       Default
            Debug "Drop onto Gadget : " + EventGadget() + ", type: " + EventDropType() + ", action: " + EventDropAction() + ", window: " + EventWindow()
            ;Further functions to handle the event may include:
            ; EventDropText(), EventDropImage(), EventDropFiles(), EventDropPrivate(),
            ; EventDropBuffer(), EventDropSize(), EventDropX(), EventDropY()
    ;     EndSelect
        
      Case #PB_Event_CloseWindow 
        Debug "CloseWindow: " + EventWindow()       ;Custom handling for specific windows is possible.
        quit = 1
      Case #PB_Event_Repaint         
        Debug "Repaint: " + EventWindow()           ;Custom handling for specific windows is possible.
      Case #PB_Event_SizeWindow      
        Debug "SizeWindow: " + EventWindow()        ;Custom handling for specific windows is possible.
      Case #PB_Event_MoveWindow      
        Debug "MoveWindow: " + EventWindow()        ;Custom handling for specific windows is possible.
      Case #PB_Event_MinimizeWindow  
        Debug "MinimizeWindow : " + EventWindow()   ;Custom handling for specific windows is possible.
      Case #PB_Event_MaximizeWindow  
        Debug "MaximizeWindow: " + EventWindow()    ;Custom handling for specific windows is possible.
      Case #PB_Event_RestoreWindow                  ;Custom handling for specific windows is possible.
        Debug "RestoreWindow: " + EventWindow()     ;Custom handling for specific windows is possible.
      Case #PB_Event_ActivateWindow  
        Debug "ActivateWindow: " + EventWindow()    ;Custom handling for specific windows is possible.
      Case #PB_Event_DeactivateWindow
        Debug "DeactivateWindow: " + EventWindow()  ;Custom handling for specific windows is possible.
      Case #PB_Event_RightClick      
        Debug "RightClick: " + EventWindow()        ;Custom handling for specific windows is possible.
      Case #PB_Event_LeftClick       
        Debug "LeftClick: " + EventWindow()         ;Custom handling for specific windows is possible.
      Case #PB_Event_LeftDoubleClick
        Debug "LeftDoubleClick: " + EventWindow()   ;Custom handling for specific windows is possible.
        
      Default
        
        If event <> 0
          ;This includes events posted with PostEvent() and all 'OS events' that are not handled by the PureBasic message loop.
          
          ;If using custom PostEvent() compare the event to their numbers for proper handling, further details may then 
          ; be obtained with:  EventWindow(), EventGadget(), EventType(), EventData()
          ;IF not using custom PostEvent(), IMHO OS events should be handled with a window callback procedure.
          
          ;Debug "Unhandled Event: " + event
        EndIf
    EndSelect
  Until event = 0 Or quit = 1
  
  Delay(10) ;Delay() frees the CPU for the multitasking
Until quit = 1

There has been postings on the meaning of events generated where the window, or gadget event is '0' (a non-documented value). For gadget events it means the gadget has only one event, such as a clicking on a check-box. For windows any events for window -1 should be ignored (as they are not valid events).


@Edit: Changed code to no longer require debugger on to run. Running it without the debugger will keep it from displaying any information but it will operate correctly.

[collectordave]

Incidentally, if the WindowCallback is used, it would handle the specific OS messages and then pass control to the PureBasic message loop to process the rest. IMHO this means that the PureBasic message loop is not the proper place to handle OS event messages (at least not in the current version of PureBasic) if you are going to handle them at all.

First I do not want to handle the specific OS messages just the official PB messages. So whatever the place to habdle OS specific messages is just not relevent.

Back to the first post. the PB function EventWindow() does not allways return the correct window on which the event occurred. Id EventWidow() returned -1 for something that is not supported then that would be OK as it would not send the message to another existent window but would be ignored.

Incidentally, if the WindowCallback is used, it would handle the specific OS messages and then pass control to the PureBasic message loop to process the rest. IMHO this means that the PureBasic message loop is not the proper place to handle OS event messages (at least not in the current version of PureBasic) if you are going to handle them at all.

I do not want to hadle them at all! Again it is the erronous result from EventWindow that causes the problem where it rerports the originating window incorrectly.

So nothing at all should get in the way.

What gets in the way is that EventWindow() does not report the correct window on which an event takes place in every case, as shown in the first post, and also does not default to -1 or a non existent window causing the meaage loop of the second window to be called.

Seems there is a lot of missunderstanding here.

1. It all has nothing to do with the messages whether PB official or not.

2. It is only the fact that EventWindow() sometimes returns an incorrect window for the originating event/ message.

Can we forget about what messages are recieved or sent. The fact, and it is a fact, EventWindow() does not allways return the correct window on which an event takes place.

[ElementE]

Fred wrote:

Some events can be fired here and here, you have to test for a specific event (like PB_Event_CloseWindow etc.). Just monitoring if a window gets an event isn't reliable (and doesn't make sens).

This sounds important.
Why is just monitoring a window for an event not sufficient?
Could someone explain this in more detail, perhaps with an example?

[said]

Hi collectordave,

Your claim is very logic but i believe you are missing an important point that Fred, TI994A, Demivec,... have been trying to explain many times, i will try (though am sure my english is far worse than theirs ) ...

The number of events managed by WaitWindowEvent()/WindowEvent() is very limited, these are called valid PB-events:
#PB_Event_Menu
#PB_Event_Gadget
#PB_Event_SysTray
#PB_Event_Timer
#PB_Event_CloseWindow
#PB_Event_Repaint
#PB_Event_SizeWindow
#PB_Event_MoveWindow
#PB_Event_MinimizeWindow
#PB_Event_MaximizeWindow
#PB_Event_RestoreWindow
#PB_Event_ActivateWindow
#PB_Event_DeactivateWindow
#PB_Event_WindowDrop
#PB_Event_GadgetDrop
#PB_Event_RightClick
#PB_Event_LeftClick
#PB_Event_LeftDoubleClick

Only AFTER a valid PB event, all related commands EventWidnow(), EventGadget(), EventMenu(), .... are expected to hold valid results.
So only after a valid PB event you can check the results of those commands; Otherwise there is no guarantee that those commands return valid result that we can use. IMO what's happening in your simple code of the 2 windows is that EventWindows() is continuously called without being updated properly because they got updated only after a PB event

If you modify your code with the below (as per PB requirements) you can see that everything is in harmony:

Code: Select all

OpenWindow(1000, 0, 0, 600, 220, "MainWindow", #PB_Window_SystemMenu)
OpenWindow(1001, 300, 300, 280, 180, "Wnd2", #PB_Window_SystemMenu)

Repeat
    
    event = WaitWindowEvent()
    Select event
        Case  #PB_Event_Menu            ,
              #PB_Event_Gadget          ,
              #PB_Event_SysTray         ,
              #PB_Event_Timer           ,
              #PB_Event_CloseWindow     ,
              #PB_Event_Repaint         ,
              #PB_Event_SizeWindow      ,
              #PB_Event_MoveWindow      ,
              #PB_Event_MinimizeWindow  ,
              #PB_Event_MaximizeWindow  ,
              #PB_Event_RestoreWindow   ,
              #PB_Event_ActivateWindow  ,
              #PB_Event_DeactivateWindow,
              #PB_Event_WindowDrop      ,
              #PB_Event_GadgetDrop      ,
              #PB_Event_RightClick      ,
              #PB_Event_LeftClick       ,
              #PB_Event_LeftDoubleClick 
           ; only after a valid event we can check the return of EventWindow()
            Select EventWindow()
                    
                Case 1001
                    Debug "Wnd2"
                    
                Case 1000
                    Debug "MainWindow"
                    
            EndSelect  ;EventWindow()
    EndSelect
    
Until event = #PB_Event_CloseWindow

I hope this helps!

[collectordave]

Hi Said

Thankyou. I wrote earlier.

I think I posted earlier, can these non official events be prevented from reaching the message loop in my program? Or is there a way of finding whether it is an official PB event so it can be discarded in my message loop before an attempt to find on which window the event occurred?

Thanks for reading it all. Your solution to the eventwindow problem works fine. Now all I have to do is add that to all main message loops in my progs where i use multiple windows.

Said Wrote

If you modify your code with the below (as per PB requirements) you can see that everything is in harmony:

Sorry about this. Checked PB help file and manual and can find no reference to this being a requirement. So maybe the PB documentation should be updated to show this?

[TI-994A]

Checked PB help file and manual and can find no reference to this being a requirement. So maybe the PB documentation should be updated to show this?

From the PureBasic documentation:

UserGuide - Building a graphical user interface

Code: Select all

  Repeat
    ; Wait until a new window or gadget event occurs.
    Event = WaitWindowEvent()
    ; In programs with more than one form, which window did the event occur on.
    EventWindow = EventWindow()
    ; Which gadget did the event occur on.
    EventGadget = EventGadget()
    ; What sort of event occurred.
    EventType = EventType()
    
    ; Take some action.
    Select Event
        
      Case #PB_Event_Gadget
        ; A gadget event occurred.
        If EventGadget = #Folder
        ElseIf EventGadget = #Files
        EndIf
        
      Case #PB_Event_CloseWindow
        ; The window was closed.
        If EventWindow = #WindowFiles
          CloseWindow(#WindowFiles)
          Break
        EndIf
        
    EndSelect
    
    ; Go round and do it again.
    ; In practice the loop isn't infinite because it can be stopped by clicking the window's Close button.
  ForEver

Nevertheless, the logical sequence in a WaitWindowEvent() loop would be to check the returned event first; and only thereafter, determine the windows, gadgets, and types.

It's programming 101; even in a C message loop, the events such as WM_CREATE, WM_PAINT, WM_DESTROY, etc., are intercepted first, before determining the window.

You're placing the horse before the cart.

[collectordave]

Couldn't agree more so

; Wait until a new window or gadget event occurs.
Event = WaitWindowEvent()
; In programs with more than one form, which window did the event occur on.
EventWindow = EventWindow()

Is what I was following and hit the problem allthough it is probably a million to one chance. The quote is from the PB documentation and is clearly incorrect as everyone has been saying.

The solution from said above should really be included in the documentation so that events are checked first and then move on to the rest.

If that had been in the documentation in the first place no problem would have occurred.

Is someone going to suggest that it be included?

[TI-994A]

Is what I was following and hit the problem allthough it is probably a million to one chance...

Not exactly.

Initially, you checked the event window first:

Code: Select all

Repeat
  event = WaitWindowEvent()
  Select EventWindow()
    Case 1001
      Debug "Wnd2"

Then, you decided to check for unofficial events:

Code: Select all

Repeat
  event = WaitWindowEvent()
  Select Event
    Case  513
      SetGadgetText(String_0,"Left Button Down")
    Case 514
      SetGadgetText(String_0,"Left Button Up")
    Case 515
      SetGadgetText(String_0,"Left Button Double Click")

The manual demonstrates the following:

Code: Select all

Select Event                         ;check the event first
  Case #PB_Event_Gadget                    
    If EventGadget = #Folder         ;then determine the gadget 
      ...
  Case #PB_Event_CloseWindow
    If EventWindow = #WindowFiles    ;or the window
        ...
EndSelect

Stick to the prescribed sequence, as indicated in the manual, and you won't go wrong.

And another word of advice; avoid using large numbers as object identifiers.

[collectordave]

Sorry but for me it is fixed.

The question now is if reference to this behaviour will be placed in the manual?

[TI-994A]

Sorry but for me it is fixed.

The question now is if reference to this behaviour will be placed in the manual?

It was never broke, and it already is in the manual.

But, if you're referring to the example that said posted, then you're out of luck:

Code: Select all

    event = WaitWindowEvent()
    Select event
        Case  #PB_Event_Menu            ,
              #PB_Event_Gadget          ,
              #PB_Event_SysTray         ,
              #PB_Event_Timer           ,
              #PB_Event_CloseWindow     ,
              #PB_Event_Repaint         ,
              #PB_Event_SizeWindow      ,
              #PB_Event_MoveWindow      ,
              #PB_Event_MinimizeWindow  ,
              #PB_Event_MaximizeWindow  ,
              #PB_Event_RestoreWindow   ,
              #PB_Event_ActivateWindow  ,
              #PB_Event_DeactivateWindow,
              #PB_Event_WindowDrop      ,
              #PB_Event_GadgetDrop      ,
              #PB_Event_RightClick      ,
              #PB_Event_LeftClick       ,
              #PB_Event_LeftDoubleClick 

He was simply making the point that events should precede any other processing. Such a bunched-case of arbitrary events is simply illogical.

[collectordave]

It was never broke, and it already is in the manual.

Just looking at manual

EventWindow()

Syntax

WindowNumber = EventWindow()
Description

After a WindowEvent() or WaitWindowEvent() function, use this function to determine on which window the event has occurred.
Parameters

None.
Return value

The window number on which the event has occured.

In some circumstances this does not do what it says in the manual. I have allways believed that a bug is an undocumented feature. Just a few words here such as it only works after an official PB event would suffice to make this not a bug.

Such a bunched-case of arbitrary events is simply illogical.

But it works.

[TI-994A]

Just looking at manual

EventWindow()
...use this function to determine on which window the event has occurred.

Return value
The window number on which the event has occurred.

What event do you assume the manual is referring to?

Code: Select all

    event = WaitWindowEvent()
    Select event
        Case  #PB_Event_Menu            ,
              #PB_Event_Gadget          ,
              #PB_Event_SysTray         ,
              #PB_Event_Timer           ,
              #PB_Event_CloseWindow     ,
              #PB_Event_Repaint         ,
              #PB_Event_SizeWindow      ,
              #PB_Event_MoveWindow      ,
              #PB_Event_MinimizeWindow  ,
              #PB_Event_MaximizeWindow  ,
              #PB_Event_RestoreWindow   ,
              #PB_Event_ActivateWindow  ,
              #PB_Event_DeactivateWindow,
              #PB_Event_WindowDrop      ,
              #PB_Event_GadgetDrop      ,
              #PB_Event_RightClick      ,
              #PB_Event_LeftClick       ,
              #PB_Event_LeftDoubleClick

But it works.

Assume you have a window with a button and a timer; how do you propose handling each of those events?

Sinking in?

[said]

@collectordave: You are welcome, good that the issue is clear now (i went thru similar trouble when starting with PB )

I agree with you the doc is not very clear about EventWindow() unlike other sister commands: EventGadget(), EventMenu(), EventTimer(), …. I think the reason for this is very simple:

EventGadget() is only affected and needed after the PB-event #PB_Event_Gadget
EventMenu() is only affected and needed after the PB-event #PB_Event_Menu
and so on …

while EventWindow() is not exclusively related to any one particular PB-event ... So if you want to check only for EventWindow() then you need to check for all possible PB-events (which was the case with your code sample)

Said

[collectordave]

Try to take tham all in turn.

Such a bunched-case of arbitrary events is simply illogical.

Far from being arbitrary the list said posted does appear to be the list of official events that windowevent() and waitwindowevent() react to.

What event do you assume the manual is referring to?

From the docs it just says event so i assume that any event that occurs is perfectly OK. If the docs said this is only valid after an official PB event then I would assume that I would need to check for an official PB event before using this function.

Assume you have a window with a button and a timer; how do you propose handling each of those events?

Code: Select all

OpenWindow(1000, 0, 0, 600, 220, "MainWindow", #PB_Window_SystemMenu)
Button_0 = ButtonGadget(#PB_Any, 130, 60, 160, 50, "")
AddWindowTimer(1000, 123, 250)
ProgressBarGadget(0, 10, 10, 380, 20, 0, 100)

Procedure.i CheckEvent(event)
    Select event
        Case  #PB_Event_Menu            ,
              #PB_Event_Gadget          ,
              #PB_Event_SysTray         ,
              #PB_Event_Timer           ,
              #PB_Event_CloseWindow     ,
              #PB_Event_Repaint         ,
              #PB_Event_SizeWindow      ,
              #PB_Event_MoveWindow      ,
              #PB_Event_MinimizeWindow  ,
              #PB_Event_MaximizeWindow  ,
              #PB_Event_RestoreWindow   ,
              #PB_Event_ActivateWindow  ,
              #PB_Event_DeactivateWindow,
              #PB_Event_WindowDrop      ,
              #PB_Event_GadgetDrop      ,
              #PB_Event_RightClick      ,
              #PB_Event_LeftClick       ,
              #PB_Event_LeftDoubleClick
          
          ProcedureReturn #True
            
        Default
          
            ProcedureReturn #False
              
          EndSelect
            
EndProcedure

Repeat
   
    event = WaitWindowEvent()

       If CheckEvent(event) = #True
         If Event = #PB_Event_Timer And EventTimer() = 123
           Value = (Value + 5) % 100
           SetGadgetState(0, Value)
         EndIf  
       
         Select EventGadget()
           Case Button_0
             Debug "buttonpressed"
       
         EndSelect
       EndIf 
Until event = #PB_Event_CloseWindow

That code appears to work;

I moved the event check to a procedure to keep the message loop clear.

I was also just checking to see why I got a little confused so looked at this piece of code from the manual

Code: Select all

    ; Wait until a new window or gadget event occurs.
    Event = WaitWindowEvent()
    ; In programs with more than one form, which window did the event occur on.
    EventWindow = EventWindow()
    ; Which gadget did the event occur on.
    EventGadget = EventGadget()
    ; What sort of event occurred.
    EventType = EventType()

Logic to me dictates that i should not do anything I do not have to.

The first thing here, after the event is recieved shows eventwindow() being used then eventgadget() and then eventtype(). As we all now know the events passed on by WaitWindowEvent() are all events not just official PB events. So all three are run everytime an event is recieved even unofficial mousemove events, of which i assume there are thousands. This seems a little illogical.

So being a newbie to this I see the official example using EventWindow() first and assume that is what you do. When things go a little awry you then check the documentation which as you can see offers no help. If when checking it stated "only valid after an official PB event" even as a newbie I would take a closer look and probably ask on the forum how to check for an official PB event.

I suggest the manual and example are modified to explain this.

[TI-994A]

Logic to me dictates that i should not do anything I do not have to.

Sound logic; try following it:

Code: Select all

wFlags = #PB_Window_SystemMenu | #PB_Window_ScreenCentered
OpenWindow(0, #PB_Ignore, #PB_Ignore, 600, 220, "MainWindow", wFlags)
ButtonGadget(0, 130, 60, 160, 50, "Button")
ProgressBarGadget(1, 10, 10, 380, 20, 0, 100)
AddWindowTimer(0, 0, 250)

Repeat
  Select WaitWindowEvent()
    Case #PB_Event_CloseWindow
      appQuit = 1
    Case #PB_Event_Timer
      If EventTimer() = 0
        Value = (Value + 5) % 100
        SetGadgetState(1, Value)
      EndIf  
    Case #PB_Event_Gadget
      If EventGadget() = 0
        Debug "buttonpressed"
      EndIf
  EndSelect
Until appQuit

The code only needs to check for the occurrence of three events; all others are moot and require no scrutiny whatsoever.

Your CheckEvent() procedure is totally unnecessary, and renders redundancy in the event loop.