mouse click injection no always handling...

Create issue
Issue #136 resolved
Former user created an issue

Automatic migration. Original reporter: "duffolonious"

start snip mouse down handler case SDL_MOUSEBUTTONDOWN: let a special function handle the mouse button down event handled = handle_mouse_down(e.button.button); if ( handled ) LogNTC("CEGUI handled mouse button"); else LogNTC("CEGUI lost focus"); break;

next snip: handle_mouse_down: bool CEGUIMgr::handle_mouse_down(Uint8 button) { bool handled = false;

switch ( button ) { handle real mouse buttons case SDL_BUTTON_LEFT: handled = CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::LeftButton); break; case SDL_BUTTON_MIDDLE: handled = CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::MiddleButton); break; case SDL_BUTTON_RIGHT: handled = CEGUI::System::getSingleton().injectMouseButtonDown(CEGUI::RightButton); break;

handle the mouse wheel case SDL_BUTTON_WHEELDOWN: handled = CEGUI::System::getSingleton().injectMouseWheelChange( -1 ); break; case SDL_BUTTON_WHEELUP: handled = CEGUI::System::getSingleton().injectMouseWheelChange( +1 ); break; } return handled; }

end snip

In this code snippet it will print "CEGUI lost focus" when I click on a FrameWindow's background - which should be handled, afaik. As opposed to clicking off of the window (on nothing CEGUI related) - which would correctly print "CEGUI lost focus".

Reproducibility: always

Comments (2)

  1. Paul Turner

    I think it should return as handled if, and only if, the Window actually did something in response - such as activating the window, bringing it to the top of the z order, or what have you. In cases where the window is already active or at the top of the z order, then nothing actually happens in response to the event and so the event should be returned as not handled (since it did nothing with it).

    So, from a cursory inspection it seems there is incorrect behaviour here, which I will fix as needed. But IMO it should not just blindly return that the event was handled every time - since this is not what is really happening.

  2. Paul Turner

    rev. 1533

    A fix is now in trunk for this. The behaviour is now as I stated earlier - if the window has to take action the event is marked handled. However, if the window takes no action (because it is already active, for example), the event is left as unhandled (since no action has been taken).

    I understand this does not fix things in a way you ideally wanted. Though if you want FrameWindow to always handle the event, you should subscribe an handler and mark it as handled yourself.

  3. Log in to comment