Event forwarding on Windows?

BlitzMax Forums/MaxGUI Module/Event forwarding on Windows?

Yasha

(Posted 2015) [#1]

I've encountered an inconsistency between platforms in the way MaxGUI seems to pass events up the TGadget hierarchy by default. Consider this (modified from the CreateTextField example to add a cancel button and a tabber):

' createtextfield.bmx

Import MaxGui.Drivers

Strict 

Local window:TGadget
Local textfield:TGadget
Local button:TGadget

window=CreateWindow("My Window",30,20,320,200)

Local tabber:TGadget = CreateTabber(0, 0, 320, 60, window)

textfield=CreateTextField(4,4,120,22,tabber)
SetGadgetText( textfield,"A textfield gadget" )

' we need an OK button to catch return key

button=CreateButton("OK",130,80,80,24,window,BUTTON_OK)
Local cancel:TGadget = CreateButton("CANCEL", 30, 80, 80, 24, window, BUTTON_CANCEL)

ActivateGadget textfield

While WaitEvent()
	Print CurrentEvent.ToString()
	Select EventID()
	Case EVENT_GADGETACTION
		Select EventSource()
			Case textfield
				Print "textfield updated"
			Case button
				Print "return key / OK button pressed"
			Case cancel
				Print "esc key / CANCEL button pressed"
		End Select
	Case EVENT_WINDOWCLOSE
		End
	End Select
Wend

On OSX, where I've been doing most of my work, this will detect all presses of Enter and Esc as long as the window is in focus. I've been attaching a (hidden) BUTTON_OK and a BUTTON_CANCEL to all of my subwindows so that I can easily dismiss them. Works great.

On Windows, as soon as I add a grouping construct (tabber, panel, etc) around some gadgets, when the gadgets within the group have focus, the buttons outside it no longer pick up events. So in the little example above, once you start typing in the box, the OK button and CANCEL button won't pick up Enter and Esc until you click on one of them and return focus to the objects outside the tab group.

I like the OSX behaviour better (certainly better than the "obvious" fix of adding a duplicate hidden OK/CANCEL to every group!). Can I make Windows behave this way?

A related issue (probably caused by the same underlying design decision) is that when a child window has focus on Windows, I find that key shortcuts powered by the main window menu (e.g. Ctrl+V) are not detected. Again, on OSX these pass straight through, which is nice for me because my app is designed to let the user open up several subwindows at once (and I can toggle visibility both ways with the shortcut, instead of only summoning them).

I'm completely unfamiliar with WinAPI programming (and a GUI n00b in general), so I don't know what the correct term for the behaviour I'm observing is ("event propagation"? "event forwarding"?). I'm guessing the solution is something to do with Subclassing window procs or WS_EX_CONTROLPARENT, but that's a guess.

What's going on here? Can I get the OSX behaviour on Windows?

Derron

(Posted 2015) [#2]

Does not work on Linux either.

BTW:
had to do

Framework Brl.StandardIO
'Import MaxGui.Drivers
'Import MaxGui.fltkmaxgui
Import Bah.gtkmaxgui
Import Brl.EventQueue
Import "-ldl"

As FLTK resulted in no GUI but some memory adressed printed to console...

I do not know MaxGUI that well, but in a "perfect" world the gadgets would either "process" an event (in wxWidgets you can "Skip/Veto/...") or they would pass it to their ancestors.

Maybe you should create some kind of "event listener" which checks all incoming events and in the case of "escape" creates a custom event which contains additional information (depending on existing gadgets / opened windows). Next to a custom event you also could inform all available gadgets (if you have some kind of "gadget-collection" for easier access).

bye
Ron

Henri

(Posted 2015) [#3]

Hi Yasha,

probably easiest way would be to modify MaxGUI a bit to add more control over what happens when enter gets pressed. Obvious place for Windows enviroment would be inside KeyboardProc() - function for 'Type TWindowsGUIDriver' located in MaxGUI.Win32MaxGUIEx.bmx - file.

-Henri

Yasha

(Posted 2015) [#4]

It isn't a solution in the general case, but for my purposes (mainly wanting hotkey events to be global regardless of child window focus) the SetHotKeyEvent procedure turns out to be a very useful feature. I can simply replace the menu-based hotkey combo with an identical globally set one after creating the menu (the menu text doesn't appear to be changed by this), and it will work without window focus since it apparently doesn't have to go through the window any more.

The OK/Cancel button thing is mildly annoying, but since they're hidden, it doesn't really matter if I just create extra ones and put them inside the grouping constructs instead.