I have an event manager that classes can subscribe to and get events dispachted. I have some objects in my scene. When one is clicked it is selected and when you click in empty space it is deselected. Simple enough. Now when you click an item I want a menu to appear so I call a method that creates a menu for me. That menu, lets call it MyCustomMenuClass (just a nice container for doing all the setup like adding buttons to windows and handling it's own events, that is the important part) Since I am handling Mouse Down in the calling class and I am not selecting a new object but rather trying to click on something in the menu, it disappears. Now the disappearing menu is not the problem, that is intended, I make a call to hide the window but what is the problem is that it should only hide the menu when I click on empty space, thus not the menu, makes it kinda useless.
static bool isMouseOverGUI = false;
if (event.MouseInput.Event == EMIE_LMOUSE_PRESSED_DOWN) {
//Check if item was clicked
// if so then show menu and select item
// else hide menu and deselect item
}
Above is the logic from OnEvent method in my class. Since it thinks that it clicked on empty space it hides the menu that is visible when I was actually just clicking on an item on the menu. What I noticed is that the event object doesn't clear out the other event types even if they haven't occurred. Otherwise I could just see if there was a GUIEvent present and bail because we want to do processing in the menu class OnEvent method.
Sorry, did not get the exact click processing order which you need. The usual tricks for similar cases are: Hiding events. Your event-receiver receives events before the gui - so if you just return true in your eventreceiver for an event which you don't want the gui to see then it will no further be processed.
The other way round is a little more tricky - checking if you can click stuff in the scene when the gui should rather receive it (more as you receive the event before the gui does). I do usually check which element is below the mouse (with guiEnv->getRootGUIElement()->getElementFromPoint) and act accordingly.
CuteAlien wrote:Sorry, did not get the exact click processing order which you need. The usual tricks for similar cases are: Hiding events. Your event-receiver receives events before the gui - so if you just return true in your eventreceiver for an event which you don't want the gui to see then it will no further be processed.
The other way round is a little more tricky - checking if you can click stuff in the scene when the gui should rather receive it (more as you receive the event before the gui does). I do usually check which element is below the mouse (with guiEnv->getRootGUIElement()->getElementFromPoint) and act accordingly.
I like your second method, as I tried the first originally before posting. But maybe I should reorder the event array to have the gui in before the scene. I'll give it a try and see if I can get it to perform properly. I thought I might have to do something like this. Problem I was seeing was I could get element lost focus and got focus but it will be sent for child elements as well and if I tried to maintain a state then it could get ugly really fast.
Do you have any plans to null out the other elements of the event receiver when sending events to the listeners? If not I might just go and add that little nugget myself, because I think it might be slow and that is why you guys didn't add it to begin with?
You cannot change the order, that is fixed. You get mouse and key events - then if you don't return true those events are passed on to the gui - then you get again the events created by the gui in your receiver. If you think a little about it then it makes probably sense (gui needs mouse+keyboard events to function - it's just not possible to do that the other way round).
I don't know what you mean with nulling-out elements.
CuteAlien wrote:You cannot change the order, that is fixed. You get mouse and key events - then if you don't return true those events are passed on to the gui - then you get again the events created by the gui in your receiver. If you think a little about it then it makes probably sense (gui needs mouse+keyboard events to function - it's just not possible to do that the other way round).
I don't know what you mean with nulling-out elements.
True, I was just talking about in my event manager class. You can register as a listener blah blah. I was just trying to find the right conditions on which I need to return in the left click event. I'll play around with checking if any gui componets are under the mouse tonight and see if I can get it cleaned up.
Side note, thanks for all the feedback and help CuteAlien. You have been great these past few months on my journey though irrlicht and I just want to let you know I appreciate your time
