CEGUI (Crazy Eddie's GUI) Forums

I've wasted half a day trying to get something pretty basic working, so I guess I'm missing something, well, basic

I want to show a layout with some windows, on top of my game. When the layout windows are clicked, I want them naturally to handle those clicks, and when the click is outside of those windows, I want them to not handle it so I know to pass the click on to my actual game.

But I can't get this to work. If the layout has a root window which covers the entire window (but transparent so I can see the game behind it), then it captures input. Specifically, it captures every *other* input, since RiseOnClck is enabled - the invisible parent layout window 'rises', no matter where I click. Which makes sense I guess since it covers the entire screen. Now, setting RiseOnClick to False doesn't work, because then the _child_ windows don't rise anymore, and I need them to react when clicked. I've also tried setting PassthroughEnabled on the root window (so it wouldn't rise when clicked, the click would 'pass through'), but RiseOnClick ignores the passthrough property - the click is stil handled despite PassthroughEnabled being true.

The other solution seems to be to not have a parent root window in the layout which covers the entire screen. So say the layout just contains a single small window somewhere. But this doesn't work either, because when I click, getTargetWindow returns the small window in my layout, even though the click isn't on it - because that window is the 'active sheet'.

I honestly at this point have no further ideas about how to solve this, so I'm posting here...

Followup: I patched my copy of CEGUI to work the way I need it to, here is the patch, perhaps it might be of use to others:

src/CEGUIWindow.cpp:onMouseButtonDown :


The simple change makes it not handle the event if, while the window rose on click, but it has mousepassthrough enabled. As the comment says, this works if we set the invisible layout root to be passthrough-enabled. When we then click outside of the visible windows, the root rises, but it isn't handled.

Hi,

sounds like a good catch. I think that CE is currently working on an overhaul to deal which situations such as these. Because now and then some forum post like yours pops up One situation that just doesn't fit exactly within the system.

This sounds similar to an issue I was having, if it's something completely different, than forgive me <3

Here was my problem: the first time you clicked on the window to interact with game controls, the mouse click was absorbed by CEGUI; the second and all subsequent mouse clicks would correctly fall through to the game. This sounds like your "captures every other input" issue.

My first reaction was to simply inject (into CEGUI) a fake mouse click at 0,0 and this fixed my problem. However, I wasn't really satisfied with that as I wanted to know if this was an actual bug in CEGUI or I was doing something wrong.

Well I did a little more digging and it turns out that when you load/set your GUISheet, it's not actually considered 'active' until an event is fired that activates the root window. So I found the simpler solution to simply call CEGUI::System::GetSingleton().getGUISheet()->activate() after the call to setGUISheet(). It would be nice if this information was listed in the tutorial, or at least the call to activate() added to the sample code ^_^

Jamarr wrote:This sounds similar to an issue I was having, if it's something completely different, than forgive me <3

Here was my problem: the first time you clicked on the window to interact with game controls, the mouse click was absorbed by CEGUI; the second and all subsequent mouse clicks would correctly fall through to the game. This sounds like your "captures every other input" issue.

My first reaction was to simply inject (into CEGUI) a fake mouse click at 0,0 and this fixed my problem. However, I wasn't really satisfied with that as I wanted to know if this was an actual bug in CEGUI or I was doing something wrong.

Well I did a little more digging and it turns out that when you load/set your GUISheet, it's not actually considered 'active' until an event is fired that activates the root window. So I found the simpler solution to simply call CEGUI::System::GetSingleton().getGUISheet()->activate() after the call to setGUISheet(). It would be nice if this information was listed in the tutorial, or at least the call to activate() added to the sample code ^_^

It sounds like a completely separate issue. In my case it absorbs every other click because of RiskOnClick, not just the first click because the layout isn't active. Also, I tried activate() on my sheet (and deactivate, and anything else I could think of), but it didn't help.

kripken wrote:It sounds like a completely separate issue. In my case it absorbs every other click because of RiskOnClick, not just the first click because the layout isn't active. Also, I tried activate() on my sheet (and deactivate, and anything else I could think of), but it didn't help.

I find that odd since I cannot reproduce that behavior, aside from what I described above. I also have a root window that encompases the entire window and is transparent; it is a "DefaultWindow" (eg: CEGUIWindow.cpp). By default, this window is visible (though transparent), has both RiseOnClick and ZOrdering enabled, and MousePassThrough disabled.

Meaning, if RiseOnClick really is the culprit, mine would be exhibiting the same behavior - but it is not. If I click outside of any non-root cegui windows, my input is handled by the game (and injectMouseButtonDown() will return false) because the root window does not consume it. I will also throw out a quote from CE himself:

crazyeddie wrote:To explain a bit more - say you had two sibling frame windows, if you clicked on the inactive one, the frame window would react to activate the window and consume the event. If the window is already active, it does nothing so the event is not consumed.

While he is talking about FrameWindows there, you can verify the highlighted behavior by simply looking at the code in CEGUIWindow.cpp. In other words, the only time a MouseButtonDown event is actually consumed is if your root window is not active (which relates back to my previous post).

Now you are saying that it happens "every other click"...well I'm saying that is not possible according to the information you have given. If you look at the CEGUI::Window code, you can see this behavior clear as day. It doesn't even care about MousePassThrough because, for a "DefaultWindow", mouse-click events are only considered handled if the window was activated. This leads me to believe that the problem lies in your code, not in CEGUI.

Are you using a "DefaultWindow" as your GUISheet?
Are you accidentally de-activiating the GUISheet somewhere in your code?

bool rose = doRiseOnClick();
e.handled |= (rose && !d_mousePassThroughEnabled);

The simple change makes it not handle the event if, while the window rose on click, but it has mousepassthrough enabled. As the comment says, this works if we set the invisible layout root to be passthrough-enabled. When we then click outside of the visible windows, the root rises, but it isn't handled.

Your reasoning does not make any sense. You are saying that when the event is handled, if MousePassThrough is enabled (which btw has no othher effect on a "DefaultWindow"!) we should hide the fact that the event was handled? That defies logic.

Thank you! Yes, it turns out that I was deactivating the GUI sheet, and that was causing the odd behaviour.

Now this leaves me with another problem, though: previously when I clicked outside of my visible windows, then I deactivated the GUI sheet. This had the effect of no longer capturing keyboard input for the editbox in my visible window. In other words, if I don't deactivate the GUI sheet then it continues to capture keyboard input, and my game doesn't receive those keypresses. What's the correct way to make it so this doesn't happen?

Well, I think specific implementions for this issue varies by application, though the general method is probably the same.

I store a cegui_keyboard_focus state. This state is nothing more than the stored result from CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::LeftButton). When the state is 1, then whenever a key is pressed I use the inject/KeyDown/KeyUp/Char methods to send the input to CEGUI. If the state is 0, then I just don't call those inject methods, and I let my game handle them instead.

Jamarr wrote:Well, I think specific implementions for this issue varies by application, though the general method is probably the same.

I store a cegui_keyboard_focus state. This state is nothing more than the stored result from CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::LeftButton). When the state is 1, then whenever a key is pressed I use the inject/KeyDown/KeyUp/Char methods to send the input to CEGUI. If the state is 0, then I just don't call those inject methods, and I let my game handle them instead.

I think I understand, so you handle this yourself manually instead of letting CEGUI do it. It sounds like it should work, thanks, I'll try it.

It is funny because I have sort of come full circle back to this issue. The same logic that allows the GUISheet to work as expected, and is explained throughout this thread, is the same logic that I recently found to be problematic.

Here is the scenario:

• An inactive window will consume a mouse-down event.
• Thus, if the GUISheet is activeted after being set, any mouse-down events on the GUISheet itself (eg, not on any child windows) will not be consumed. This allows the event to be passed onto the application.
• Likewise, if the GUISheet is active, a mouse-down event on an inactive child-window will be consumed by CEGUI. This gives the desired effect this thread was all about: allowing the user to switch input contexts depending on what they clicked on.
  
• However, an active window will not consume a mouse-down event.
• Because this behavior is exibited for all elements, a mouse-down event on an already active child-window will /not/ consume the event, which brings us right back to square 1 - the user is specifically clicking on a CEGUI element but instead of being consumed by CEGUI is mistakenly handed off to the application and doing who-knows-what.

The delima here is that we obviously want this behavior for the GUISheet, but we want a different behavior for the child-windows (consuming mouse-down events even if it is already active).

The normal behavior that the GUISheet should exhibit is to allow all mouse-down events that /do not hit/ any child-windows to passthrough to the application, while all mouse-down events that /do hit/ child-windows, even if they are already active, should be consumed /unless/ the child-window has passthrough enabled.

Unfortunately, the logical behavior is not the default behavior in CEGUI. Luckily I was able to work around this issue, and implement the logical window behavior without having to modify the CEGUI source, but it is a bit crude.

This is (essentially) the code I use to acheive this behavior:


Now I just have to ask...am I completely overlooking something here? Is there some reason why the logical behavior one would expect is not the default behavior CEGUI exhibits? I can't understand how this would go unnoticed for so long unless I'm doing it wrong, or unless /everyone/ just works around it...

@Jamarr:
The current 'inconsistent' behaviour was introduced by me when I 'fixed' an issue related to events for the 0.6.0 release. It wasn't until afterwards that it became apparent as to the size of the can of worms that I'd opened up

As scriptkid mentioned above, this is something that I will be addressing; although I have not stared any work on it at the present time, and as such have not come up with a final plan for how to handle these things, though I have a couple of ideas to try out when I get some time to work on CEGUI.

CE.

I see. Thank you for the reply. I just wanted to make sure that I was not overlooking something ^_^