Erroneous, no. As per the rules of the language construct, polling EventWindow() at the inappropriate time would definitely yield inaccurate results. But even so, branching to any window's event handler when there are no relevant events to process is not consequential, as the code would simply flow through and return.
Erroneous yes. EventWindow only returns a valid window number after a valid PB event.. As per the rules in the help file.
After a WindowEvent() or WaitWindowEvent() function, use this function to determine on which window the event has occurred.
The valid PB event is not mentioned just "event". I am assuming nothing here just that after an event it returns the window on which the event occurred as stated.
With all due respect, we do understand your intended approach. Technically, there's nothing wrong in applying an extra check before routing events to their target windows. However, it's simply redundant to do so, and as the BindGadgetEvent() example in the other thread has shown, redundancy can sometimes cause problems.
Events should simply be allowed to flow through, with only the required ones intercepted and processed.
In my original programme I allowed events to simply flow through as you say believing all to be Ok. I reached a point where the user enters values on a secondary window which affect the display on the main window and started to notice some strange effects. This started me on the investigation into my programme to see where I had gone wrong. Which is where I had reached when posting the first example multiple window.
I have rewritten the example to show this a little clearer, code below:-
Code: Select all
frmMain = OpenWindow(#PB_Any, 0, 0, 600, 220, "", #PB_Window_SystemMenu)
CreateMenu(100, WindowID(frmMain))
MenuTitle("File")
MenuItem(101, "Open")
String_0 = StringGadget(#PB_Any, 80, 30, 310, 30, "")
Repeat
event = WaitWindowEvent()
If EventWindow() = Wnd2;Select window.
Window2::Event_Handler(event)
SetGadgetText(String_0,"")
counter = counter + 1
SetGadgetText(String_0,Str(counter))
EndIf ;EventWindow()
;Not the second window so must be the main window
Select event
Case #PB_Event_Menu
Select EventMenu()
;Only one menu item
Case 101
;Show the 2nd window
Debug "Open 2nd"
Wnd2 = Window2::OpenWnd2()
EndSelect ;Eventmenu
Case #PB_Event_CloseWindow
End
EndSelect ;Event
ForEver
and second window
Code: Select all
DeclareModule Window2
Global ThisWindow.l
Global Ok.i = 0
Declare.l OpenWnd2()
Declare Event_Handler(event)
EndDeclareModule
Module Window2
Global btnOk, btnCancel
Procedure.l OpenWnd2()
ThisWindow = OpenWindow(#PB_Any, 300, 300, 280, 180, "Test Window", #PB_Window_SystemMenu)
btnOk = ButtonGadget(#PB_Any, 130, 140, 60, 30, "Ok")
btnCancel = ButtonGadget(#PB_Any, 210, 140, 60, 30, "Cancel")
ProcedureReturn ThisWindow
EndProcedure
Procedure Event_Handler(event)
Select event
Case #PB_Event_CloseWindow
CloseWindow(ThisWindow)
Case #PB_Event_Gadget
Select EventGadget()
Case btnOk
Ok = 1
CloseWindow(ThisWindow)
Case btnCancel
Ok = 0
CloseWindow(ThisWindow)
EndSelect
EndSelect
EndProcedure
EndModule
Simply open the second window and the stringgadget will start to count and will keep counting until you cause another valid PB event. Just move your mouse away from all windows to see this the only events happening then are the events on window 1 where the stringgadget text is being changed. However the counter is only increased when a window 2 event is recieved!
The result of the first post explained that only after a valid PB event could eventwindow() be counted on. Which was the birth of this procedure.
When I am coding I like to try to elliminate as many potential bugs as possible so, thanks to another forum user who wrote this originally as they also had problems, I check for all valid PB events straight away. Adding the check to the programme above elliminates the problem. However please do not assume that the check will be in the finished programme as after completing the programme I will revisit this procedure and at the very least remove redundant event checks. One which springs to mind here is the timer event which i am not using at the present time. It may also result in the check being elliminated alltogether, but I will have to wait and see.
This is not a critisism of PB just the help file. If event window was stated that it was valid only after a valid PB event I would have gone away and written this procedure and not published at all. Assuming that everyone else had faced the same problem and overcome it in their own way.
Now to move on a little.
I do understand that all windows,gadgets and menus etc have to have unique identifiers. I started with Pure Basic trying to invent lots and lots of unique identifiers using enumerations etc and the list did look quite impressive in my code. I did get some wrong and watched my gadgets disappear. I then started to invent lots and lots of variable names and to use #PB_Any to assign the values to these variables. Thankfully before going to far I discovered modules. So now where I have a button on a window that the user clicks to say "Ok" I can simply call them all btn_Ok in the knowledge that it will not clash with others in other windows etc that have the same variable name. This also makes coding multiple windows with roughly the same content and operation a breeze. However the importance of eventwindow() becomes very clear.
Any intelligent fool can make things bigger and more complex. It takes a touch of genius — and a lot of courage to move in the opposite direction.