MaxGUI + Key Events?
BlitzMax Forums/BlitzMax Beginners Area/MaxGUI + Key Events?
| ||
| No key or mouse events are emitted in my MaxGUI application, though I hit keys. How can I receive them? I'm using a hook function to EmitEventHook and calling WaitSystem in my main loop. A DebugLog event.ToString() shows lots of gadget related events, but nothing for keys or mouse. |
| ||
| It depends on the control which events are fired. Key and Mouse events are only fired by a panel (set to PANEL_ACTIVE) and Canvases. |
| ||
| Oh, so I can't just generally handle all KEY_ENTER events? |
| ||
| I created a parent panel for all the gadgets in the window. I receive mouse events all right and also receive key events until I use another gadget (eg. click a button). I'm basically trying to catch KEY_ENTER and KEY_DELETE events for a list box (though I'd like them to work no matter where in the GUI the focus is), so the panel solution does not work. |
| ||
| You can use SetGadgetSensitivity(), but I've no idea how good (or bad it is). You'd probably need to set it for all gadgets too... :-) |
| ||
| Docs for SetGadgetSensitivity: As a result, it is to be recommended that this function is only used by advanced MaxGUI users. Well, I'm not an advanced MaxGUI user, but I gave it a go. After setting it for all gadgets, it works alright with KEY_DELETE, but KEY_ENTER only emits EVENT_KEYUP events! Depending on the active gadget, an EVENT_GADGETACTION event or something else *may* be emitted on key-down, but nothing on key-repeat. In the case of ListBox, nothing is emitted. Do I have a completely wrong approach to the problem at hand? |
| ||
| Possibly a limitation of MaxGUI. If Seb passes by, he'll be able to provide more useful information than me. |
| ||
| The Enter key historically needs to be caught by the owner windows OK button, hidden if you must. This is due to 20+ years of MS user interface design guidelines where the primary directive is not to alienate users by having the Enter key perform different tasks based on the gadget / item that owns focus in any one form or window. I suspect it is small things like this that makes every windows app different so perhaps worth the sometimes illogical approach of a hidden OK button event source, it certainly makes for cleaner event management under the hood. |
| ||
| The Enter key historically needs to be caught by the owner windows OK button, hidden if you must. Thanks... Then I suspect it's the same with Esc & Cancel? I think I'll try a hidden-button-approach, then. Edit: Works! Though I fail to see how directing events from the hidden OK button to ActiveGadget makes for cleaner event management... |
| ||
| For child forms I would hope most people would want to always maintain the standard OK CANCEL hot-key mappings. For main app windows your expectations are possibly more than valid. For windows items isn't F2 traditionally the shortcut for the Edit/Rename operation anyway? |
   |