Problem with separate character and key event callbacks

fractile wrote on Tuesday, December 09, 2014:

I open a chat dialog based on key callback (GLFW_KEY_T) and process text input in character callback. The problem is that now the T -key press produces two separate callbacks, first opens the dialog and second enters character ‘t’ in text input (which I obviously don’t want).

Only solution I can think of is to set a flag when opening the dialog in key callback and then ignore first character of text input in character callback based on the flag. This is really ugly and breaks down if key for opening the dialog is changed to some key that does not produce character input.

How have other people solved similar problems with two separate input callbacks?

dougbinks wrote on Tuesday, December 09, 2014:

The logic I’m currently using is that my physical key processing sends an internal message which are only processed after the GLFW event loop, so the handler for text input (and the redirection of char input to it) only occurs after any char corresponding to the key which triggered the handler has been processed.

An alternative might be to have input modes: KEYPRESS, CHARSTART, CHARPROCESS and perhaps CHAREND. When you get a key callback to start processsing chars you move from KEYPRESS to CHARSTART, and after the event loop if you detect you are in CHARSTART you move to CHARPROCESS. You only process char messages in CHARPROCESS. Note you could also only set the char callback to a non NULL function pointer if you are in CHARPROCESS.

Hope that makes senses!

fractile wrote on Tuesday, December 09, 2014:

That makes sense. I ended up setting a simple “ignore character input” flag when the dialog opens (in key callback) and resetting it after event loop processing.

Thanks for the help!