SetVisible(false) causes leaveEvent
I have got a widget with leaveEvent overridden. A signal is emitted when the mouse leaves the widget and setVisible(false) of the widget is called. This causes another leaveEvent even though the widget never got entered again. How can I stop this second leaveEvent?
Stopping the last leaveEvent will be impossible if you ask me.
In the leaseEvent check what kind of QEvent it is and handle it from there. That's what I would try.
It is the same type. Shouldn't it be wrong if there were two different types?
From my point of view a leave event should never be able to occure without an enter event before.
But they are the same event. Your right about that!
Think about it. The mouse is on the widget. It gets hidden (show()), so the system will see that the mouse isn't over the widget anymore, so emits the event.
Maybe try to check if the widget is shown (isVisible()), if so, handle the event, if not. Ignore the event
The mouse is not over the widget. That's why the first leaveEvent comes. Now the mouse is elsewhere but for sure not over the widget and then I call the setVisible(false) and the leaveEvent comes again.
For me this seems more like a bug then a desired factuality.
You can file bug reports at http://bugreports.qt-project.org/
ChrisW67 last edited by
I am intrigued to know why you care and think you need to suppress the second event (if there is one, I haven't checked). What are you doing the leaveEvent() handler? Can it/should it be done elsewhere?
Your right that when the mouse leaves the widget to get a leaveEvent, but when the mouse isn't over the widget and the widget is made invisible it sounds pretty strange to get a leaveEvent. Your right about that. Like JKSH says, file in a bug report. They might explain how it happens and why, please let us know as well.
Suppressing the second event isn't hard, but do you want to achieve? We might have a different idea.
I always can suppress things I don't want to have but for me it is logically wrong to get leaveEvents without enterEvents. Additionally emitting "wrong" signals can be avoided.
I filed a bug report. Maybe there is a good explanation for this behaviour I cannot see at the moment.