EventMouseLeaves firing when a window is destroyed? [SOLVED]

[agamemnus]

I noticed that when a window is destroyed, its mouse out event fires. This caused a crash in my program because my the mouse out event used the window's ID, which was no longer valid (that part had been cleared already I guess?).

I went around this problem by unsubscribing from all events using "removeAllEvents" before calling the window destroy function.

I find the behavior of calling the mouseout event when a window is destroyed very odd and I think it's a bug. Even assuming that it's not a bug, the mouseout event shouldn't be fired after the window ID is cleared!

[CrazyEddie]

mouseout? What is that? There is no mouseout event. Do you mean EventMouseLeaves or something along those lines? If so, firing the event is intentional.

Where is your CEGUI.log file? What is the exact 'crash' you're seeing? Why did you not post this information? Surely you have been around long enough now to know that without the log, exception details and a backtrace / callstack with debugging symbols, people can't begin to understand the exact issue and determine whether it's a user error or maybe a CEGUI issue.

CE.

[agamemnus]

mouseout? What is that? There is no mouseout event. Do you mean EventMouseLeaves or something along those lines? If so, firing the event is intentional.

Where is your CEGUI.log file? What is the exact 'crash' you're seeing? Why did you not post this information? Surely you have been around long enough now to know that without the log, exception details and a backtrace / callstack with debugging symbols, people can't begin to understand the exact issue and determine whether it's a user error or maybe a CEGUI issue.

CE.

Yes.. EventMouseLeaves... I thought I was clear, but I'll explain again. (and it's not in the log)

There's a slight change from my initial post as I debugged more thoroughly this time...
The parent is "0" (getParent returns 0), and my program crashes when my function tries to get the window's parent's ID... it was a many-layered thing:

Code: Select all

 return (*(cptr(subname ptr, cegui.getId(cegui.getParent(cegui.getWindow(eventPtr)))))).funcname (eventPtr, cegui.getId(cegui.getWindow (eventPtr)) )


So, I think that CEGUI simply detaches the window before calling the "EventMouseLeaves"... it should be detaching it after.

Beyond that, I don't understand the logic of automatically calling the "EventMouseLeaves" event before a window is destroyed. There is already an EventDestructionStarted that handles that if the user really needs an event when he's destroying a window.

[CrazyEddie]

Yes.. EventMouseLeaves... I thought I was clear, but I'll explain again. (and it's not in the log)

What's not in the log? You don't know, because you don't know what I wanted to look at in the log. I didn't ask if x, y or z were in the log, I asked you to post the log along with other information. Do you understand? When I ask for specific information, if you will not post that information, I suggest that you do not post at all.

As far as the code you posted, why are you accessing the parent without checking that it's valid? The Window::getParent function can return 0 to indicate that the window is not attached to any other window, this is within the specification for the function as per the documentation (http://cegui.org.uk/docs/current/classC ... 5128f1d3ae). There is no CEGUI issue here: fix your own code!

CE.

[agamemnus]

There is nothing in the logs after the image data and styling data is loaded, so it isn't it reasonable to assume that the log won't help anything in this case??

The Window::getParent function can return 0 to indicate that the window is not attached to any other window, this is within the specification for the function as per the documentation (http://cegui.org.uk/docs/current/classC ... 5128f1d3ae). There is no CEGUI issue here: fix your own code!

CE.

So.... let me clarify... The window that is destroyed has a parent. So, it seems the order of the destroy function is:

* Detach.
* Call EventMouseLeaves

That's wrong.

Are you saying that it's totally fine that CEGUI is (incorrectly, imo) calling "EventMouseLeaves" when a window is destroyed, and that I should know that the window detaches itself before calling "EventMouseLeaves"? And it's nowhere in the documentation that these things happen, Maybe I should know all this by "checking the code", or perhaps memorizing it.

I stand by my statement that it doesn't make sense when there's already a destruction event.

So just tell me this... do you consider any of these a bug, or not? If you don't, that's no big deal; my wrapper notes will consider this a bug, and I will add an event detach function in my window destruction wrapper function to avoid the bug.

[agamemnus]

I'd also like to add that I see how a mouseout or "EventMouseLeaves" event makes sense if the mouse is actually over the window in question at the time that the window is removed!

[CrazyEddie]

I see how a mouseout or "EventMouseLeaves" event makes sense if the mouse is actually over the window in question at the time that the window is removed!

Yeah, this is correct, and is why the sequence occurs in the order that it does. I honestly do not consider this a bug, it's consistent behaviour (i.e. the same thing happens if you manually detach the child from the parent) and, as already stated, the fact that Window::getParent can return 0 should really be tested for.

CE.

[agamemnus]

I see how a mouseout or "EventMouseLeaves" event makes sense if the mouse is actually over the window in question at the time that the window is removed!

Yeah, this is correct, and is why the sequence occurs in the order that it does. I honestly do not consider this a bug, it's consistent behaviour (i.e. the same thing happens if you manually detach the child from the parent) and, as already stated, the fact that Window::getParent can return 0 should really be tested for.

CE.

But that's just it. The "EventMouseLeaves"/mouseout event occurs even if the mouse is not hovering over the window!

If it's all the same to you, then, I would ask that the parent detach after the "EventMouseLeaves". My event function requires a parent, because when the window is moused over (or out), the parent's "status bar" updates. If there's no parent, the status bar does not update because the program doesn't know which status bar to update.

If you don't want to switch the order, at least tell me where it is so I can fix it myself. I could try using a "destruction begins" function, but (1) I haven't tested if even that is called after the detach and (2) that's an extra function when only one would do.

[CrazyEddie]

But that's just it. The "EventMouseLeaves"/mouseout event occurs even if the mouse is not hovering over the window!

I just tested this. The event is only fired for the window that contained the mouse when destruction was initiated.

My event function requires a parent, because when the window is moused over (or out), the parent's "status bar" updates. If there's no parent, the status bar does not update because the program doesn't know which status bar to update.

In your event handler, all you have to do is add some protection for the case when there is no parent.

If you don't want to switch the order, at least tell me where it is so I can fix it myself.

It doesn't need 'fixing', because it's not an issue. However, if you can find this as part of the normal control logic used in CEGUI::System::updateWindowContainingMouse().

CE.

[agamemnus]

But that's just it. The "EventMouseLeaves"/mouseout event occurs even if the mouse is not hovering over the window!

I just tested this. The event is only fired for the window that contained the mouse when destruction was initiated.

I'll check again... perhaps it's called even if not moused over in special circumstances, somehow.

In your event handler, all you have to do is add some protection for the case when there is no parent.

But I need to use the parent. So, it (switching the order of the detach and the mouse event) is an (easily fixable) issue. If I add a "no-parent protection", my program would not clear the window's status bar! (which is bad!)

I just don't see how you think that it makes sense to keep the order as it is. Shouldn't programs have as many opportunities as they can to access whatever they need? It's creating a potential unnecessary and arbitrary problem (and in my case, a definite one) to detach the window before calling the event.

part of the normal control logic used in CEGUI::System::updateWindowContainingMouse().

Thanks, I'll take a look.

[agamemnus]

Ok, it's no longer firing when I'm not moused over... that part must have been my bad. Still trying to figure out the detaching process, though. "CEGUI::System::updateWindowContainingMouse" doesn't do any detaching... I need to know where it does the detaching and where it calls the mouseleaves event...

[CrazyEddie]

The window is detached because it is about to be destroyed. The event is fired (by the previously linked function) because the window that used to contain the mouse, no longer contains the mouse, since it was detached from the window hierarchy of the active GUI sheet / root window.

CE.

[agamemnus]

I see... so it's more of an automatic thing (chain of events) than something by design... maybe it should be by design.

I went through the destruction function and I still don't understand where it occurs... where does this all occur?

[agamemnus]

Dunno if anyone cares, but here's one fix that works for me.

CEGUIWindowManager.cpp, line 221:

Code: Select all

        if (wnd == CEGUI::System::getSingleton ().getWindowContainingMouse()) {
         MouseEventArgs ma(0);
         ma.window = wnd;
         ma.sysKeys = 0; ma.wheelChange = 0; ma.clickCount = 0; ma.button = NoButton;
         wnd->onMouseLeaves(ma);
         wnd->removeEvent(Window::EventMouseLeaves);
        }