Capture click events not handled by CEGUI

[gring]

Hi,

When using CEGUI in my application, i would like to pass mouse key events not handled by any CEGUI window down to my app, where I pass this to my collision detection routine. My first solution was to check the return value from the inject methods, to see if CEGUI handled it. This solution inhibits me to use click double click functionality from CEGUI, I have to implement this again in my own collision detection. Then i tried to do it the other way, have the 'root' window cover the screen where i can subscribe to the CEGUI events for different inputs like click, double click and more. This though seem to have focus issues cause the 'root' window doesn't handle active(focus) state as the other windows.

currently i get the behaviour that no messages are passed through to root until user has clicked on a cegui button, odd that messages get forwarded afterwards.

We are using 0.6.2b libraries.

What is the recommended solution to pass click events down to the application using CEGUI?

Thanks,

/G

[CrazyEddie]

currently i get the behaviour that no messages are passed through to root until user has clicked on a cegui button, odd that messages get forwarded afterwards.

Did you try activating the root window in code, after you've created / loaded the layout? I have no real idea why the events are not being triggered though, as you'd expect, it should work - unless you have mouse passthrough enabled on the root, or if the window you're subscribing to is actually covered by another transparent DefaultWindow or something.



CE.

[gring]

Hi,

Yeah i've tried doing an activate, but i don't get the wanted behaviour since activate works like this:

Code: Select all

/*************************************************************************
   Activate the Window giving it input focus and bringing it to the top
   of all non always-on-top Windows.
*************************************************************************/
void Window::activate(void)

Litterally i can't activate background window since it's moved to the front.

And also tried to force capture input to the root window but since this code i can't do that either

Code: Select all

bool Window::captureInput(void)
{
    // we can only capture if we are the active window (LEAVE THIS ALONE!)
    if (!isActive())
        return false;

But to narrow the problem area a bit. If I add a subscription of clicks to root window of Sample_FirstWindow project, like this:

Code: Select all

   DefaultWindow* root = (DefaultWindow*)winMgr.createWindow("DefaultWindow", "Root");

    // set the GUI root window (also known as the GUI "sheet"), so the gui we set up
    // will be visible.
    System::getSingleton().setGUISheet(root);

   root->subscribeEvent(Window::EventMouseClick, Event::Subscriber(&FirstWindowSample::evClicked, this));

I get the same issue in that easy sample app. Clicks outside the window are not forwarded to the subscriber. It looks like subscriptions on 'root' to get input events outside any window aren't valid.


/G

[CrazyEddie]

Hi,

Thanks for the additional testing you've done. I'll try to investigate this a little - probably over the weekend - because this should really be working

CE.

[CrazyEddie]

I tested this a little this morning, but was not able to produce an issue. So this means either you're doing something wrong, or that I misunderstood the issue completely:)

Basically what I did was to duplicate what you suggested with regards to Sample_FirstWindow, except I extended that with handlers for click, double-click and triple-click. I use the handlers to increment a counter for each of the click types and to set the titlebar text of the demo's frame window with the counts - so basically a way to see what handlers get called.

Everything was called as I would expect, so I'm not sure what's happening there. In the test you did yourself with Sample_FirstWindow, what renderer was being used? I tested OpenGL and Irrlicht (not that this is particularly relevant, just that I guess there's potential for differences in the underlying sample base apps).

Normally I'd suggest something like the possibility of there being 'invisible' parts of other windows 'in the way', but that would not be the case with Sample_FirstWindow - so I can't explain it.

CE.

[gring]

Hi

Thanks for checking CE, I'll investigate the issue a bit further tomorrow...

Very much appreciated, that you put so much effort into supporting and replying to all issues with CEGUI.

/G

[CrazyEddie]

Hey, no problemo - I'm happy to try and support CEGUI and it's users to the best of my ability; although sometimes that role does frustrate me

There are some issues with events that we need to address, and this will be worked on for 0.7.0, though I'm still not sure what the issue is with the events not firing on your root.

CE.

[gring]

Hi,

It was my mistake, had done a strange merge of an old cegui version. Sorry for taking up your time...

Everything works just fine, my mistake.

Merry Christmas

/G