CEGUI (Crazy Eddie's GUI) Forums

Good day!

And now again for more trouble with the CEGUI-input.

First off, I use the deactivation-hack described somewhere in the forums, which works fine (the right window gets the right input).

But now, that I implemented a state-handler for my game (up to now it's Intro, Main Menu and Play-states). Since the best solution for passing on GUI-input and hiding/showing the right elements of the GUI easily was to make a DefaultWindow for each state that is active (more than one state can be active at the same time).
That means input is checked as follows:


with injectMouseButtonDown going this way:
root-window -> gamestate-base-window -> actual GUI

The gamestate-base-window has been created as follows:


Now, the problem is, that injectMouseButtonDown always returns false, even if a Window has handled its input correctly (which ends in having 3D-mouse-picking happening everywhere on the screen).

Is there any hack so that I can make distributed inputs tell that they have handled the click?
Or is there any "right" way to implement game-state-handling (with keeping some state alive while switching to another (actual game should not end, just because I switch to the main-menu) )?

Greetings 3-R4Z0R

3-R4Z0R wrote:First off, I use the deactivation-hack described somewhere in the forums, which works fine (the right window gets the right input).

Huh? Not sure what that is, if you think it's important, please link to the relevant post so I/we know what you're referring to.

3-R4Z0R wrote:Now, the problem is, that injectMouseButtonDown always returns false, even if a Window has handled its input correctly (which ends in having 3D-mouse-picking happening everywhere on the screen).

This issue is dealt with many times here on the forum; unfortunately at the moment there is no ideal - one size fits all - solution. It's my fault this happens, of course

While there are various topics covering this, like this one, I'll offer another version of a possible solution that may or may not be appropriate for your specific case...

What you might do is globally (CEGUI::GlobalEventSet) subscribe a handler to the events that are generated in response to injected inputs (like Window::EventMouseButtonDown and so on), in the handler, check if the window in the WindowEventArgs is the root window, if it isn't the root window return true from the handler to make the inject* function return true, if the window is the root window, return false.

If you're not sure how to use the global event set, search because it's been covered a few times.

HTH

CE.

CrazyEddie wrote:Huh? Not sure what that is, if you think it's important, please link to the relevant post so I/we know what you're referring to.

That was just the hack deactivating the current window so that it will take new input. Mabe that hack is deprecated now with the new hack ^^

CrazyEddie wrote:While there are various topics covering this, like this one, I'll offer another version of a possible solution that may or may not be appropriate for your specific case...

Linking to this page using System::getWindowContainingMouse.

Thank you very much, that did the trick (now I just have to find out another bug that OIS doesn't seem to call OnMouseMoved)!
I searched the forums (too short I'd say... apoligies for that ), but didn't know where to start my search and what to search for.

Doing it "globally (CEGUI::GlobalEventSet)" does seem as a lot of work for something that can be hacked somehow in much less code, so I'll try the solution you gave me and see what won't work that way.

So now I'll continue my work and see when the next bug bugs me

Greetings 3-R4Z0R

Yeah, this whole debacle is an 'egg on face' moment for ol' CE here, but these things happen to the best of us every now and then I'm going to rejig some of the event injection stuff for the 0.7.0 release and that will resolve this issue, though obviously 0.7.0 in itself will being a whole raft of new bugs for people to play with

CE.