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:

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.

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?