[SOLVED w/ workaround] BUG:Events not bubbled

[Leftium]

Short description: CEGUI does not bubble/propagate events as expected. I expect the up/down arrow keys to page through the history whenever the Console window or any of its child windows has input focus. Also, I expect F12 to always toggle the Console no matter where the input focus is unless another control is expected to 'eat' the event and stop event bubbling/propagation. I am fairly confident this is a bug because it is easy to reproduce with Sample_FalagardDemo1.exe from the CEGUI binary demos. Also don't forget to check out my Python port of the Falagard Demo at the end of this post~

Setup:

1. Start Sample_FalagardDemo1.exe
2. Click the Console window's editBox to give focus
3. Press 1, ENTER, 2, ENTER, 3, ENTER to seed the history multiline editbox with some input

Repro steps:

1. Press UPARROW
2. Click on the Console window title bar (or anywhere else inside the Console window but outside its child windows)
3. Press UPARROW, UPARROW (twice)
4. Press F12

Actual Results:

1. Nothing
2. Text cursor disappears (as expected)
3. Console window's editbox text changed to '3'
4. Nothing

Expected Results:

1. Console windows's editbox text changed to '3'
2. Text cursor disappears (as expected)
3. Console window's editbox contents changed to '2', then '1'
4. Console window is hidden

Notes:

• This bug also reproduces with a PyCEGUI port of the Falagard demo (attached below). Additionally, F12 does not toggle the Console directly after clicking the Console title (which does work with the binary demo).Even after modifying the event handlers to always return False, the events are not propagated.
• Originally I thought this was just a problem with the CEGUI Python bindings (exception messages associated with the event callback methods seem to indicate the callback method return value is None, i.e. ignored), but it seems to be a problem in both the bindings and CEGUI library.

Environment:

• Windows 7
• Python 2.6.6
• PyCEGUI 0.7.5 for Python 2.6

I discovered this bug while developing a graphical Python-interpreter shell. The goal is to be able to call PyCEGUI functions from the shell and immediately see their effects! The current code is simply a port of the Falagard console demo. However, it provides the base code for any PyCEGUI application.

Notes:

• class PyCeguiGlutBaseApp is roughly equivalent to C++ class CEGuiOpenGLBaseApplication
• class PyFalagardDemo is roughly equivalent to C++ class FalagardDemo1Sample
• class Console is roughly equivalent to C++ class DemoConsole
• there is some basic debug information logged to the (real Windows OS) console when keyboard events are injected
• function pprint_attributes() is a handy method to inspect the nested objects from the PyCEGUI API

Code for Python port of Falagard demo updated in this post.

[Kulik]

CrazyEddie plans to revisit input injection and handling in CEGUI 0.8. The grand plan is to sort out all of these oddities (as you reported), support touch devices (or even keyboard-only devices), work with mouse wheel as expected (it should act like a key event, not like a mouse click event) and several related problems. Release date is planned in the first half of this year. Unfortunately (from what I"ve heard in the IRC channel) it likely won't get into 0.7.x because it breaks code for some people who rely on this behaviour.

Your falagard demo port is highly appreciated!

We plan to add demo browser functionality to 0.8 and eventually support C++, Lua and Python demos all in one demo browser.

Python immediate console is definitely a great idea that was on my todo list quite some time but I never got around to implement it. IMO it would be a great learning tool as Python and C++ APIs are quite similar and being able to immediately see results without recompiling is awesome (also you don't have to come up with all the init and finalisation code when you are starting to evaluate CEGUI). Perhaps we could add it as a demo to 0.8. A great bonus feature would be code completion using python's introspection features.

PS: This definitely gets the "Forum post of the month (tm)" award I just invented

[Leftium]

Cool, eagerly awaiting CEGUI 0.8.0, then.

In the meantime, are there any possible 0.7.5 workarounds like manually sending events to other windows to achieve the expected behavior?

[Jamarr]

For keyboard events, there is no mechanism to enable input propagation to my knowledge. This is a long standing problem with CEGUI and one I have written a few threads on. All events should, or at least have the facility too, propagate until handled in my opinion. I asked CE for this in v0.6 but he shot me down >_>

Anyway, in the mean time I think you can get by subscribing to global events and then parsing/filtering the associated event/window data to determine how/where to handle the event; just search for forums for subscribe global event or similar.

Alternatively, you could look into the MouseInputPropagationEnabled code and perhaps hack similar functionality for keyboard propagation. Not sure how feasible this is, since I have not looked at the event code since v0.6.

To elaborate on your implied work around, you could also pre-filter (before sending to CEGUI) the keyboard events and use window hit-testing/etc. to determine where to manually inject events, but there is no need to re-invent the wheel. CEGUI's event system already does this so you may as well use it (and go with global events).

[CrazyEddie]

Ok...

First, thanks to Leftium for such a detailed report - if only all reports were like this I tested things as described, and confirm the behaviour you experienced as regards to keyboard inputs.

The situation with keyboard input propagation in 0.7.x is as follows: while a key input is not marked as handled it will always propagate back up the hierarchy, in the case where an editbox type widget is encountered, propagation stops. Now this is obviously where the issue is caused since all key input propagation is stopped at this point - which may be a little over-zealous. I have added a mantis ticket in order that I investigate the various options open to us surrounding this (while the solution is "obvious", experience has shown that a small seemingly inconsequential tweak to input handling can have massive unforeseen effects).

CE.

[Leftium]

Thanks! Global events did not solve the problem, but they led me to a workaround where I attach my keyboard handlers to custom global events. I inject the custom keyboard events in addition to the regular events. Thus my keyboard event handlers and the CEGUI built-in handlers no longer interfere with each other. Since the custom events are global, I ignore the events if target_window.getActiveChild() returns NULL.

Also I did not realize it before, but the problem is indeed limited to just editboxes.

I posted the completed Python port of the Falagard demo in another post.

References:

• Re: Subscribing to global keyboard events?
• Same event to all Button element. [solved]

Note custom events don't have an event namespace but the event name should be prepended with a '/' as in '/customEvent'. (And I couldn't figure out how to add a custom namespace like 'App/customEvent').

Also, I found some more minor issues with the CEGUI Python bindings:

• The .handled attribute of a custom global event is not maintained. It seems the object given to the handler is different than the one that is fired. The Python port linked above is automatically set to show debugging output that demonstrates this. Just press F12 to reproduce. I set the value of .handled to 100, but it has no effect outside the handler.
• The .queueID attribute is not accessible from an EventRenderQueueStarted event handler. (There was a static_cast in the C++ code.)

Finally, a few bugs I found in the native Falagard demo while porting:

• "if (shift)" should be "if (ctrl)"/"if (alt)" for the other modifier keys
• The variable int CEGuiOpenGLBaseApplication::d_fps_value = 0 is never used. [CEGuiOpenGLBaseApplication::handleModifierKeys() @CEGuiOpenGLBaseApplication.cpp]

[Kulik]

As for the PyCEGUI bugs
1) I thought I was passing EventArgs as copies but actually I am not. Maybe it is related to the specific EventArgs inherited class you posted. I will investigate this. I never noticed this issue so thanks for raising it!
2) I think I am missing some types in the subscribeEvent code, I will look into it and hopefully finally craft working Python 2.7 bindings