[fixed]Bug with modal gui windows

[Reiko]

If a modal gui window doesn't have focus while being removed, the modal state is never reset and so the whole gui becomes locked.

As a temporary work around, removing the window like this instead:

Code: Select all

guienv->setFocus(theWindow);
theWindow->remove();

so that the window gets focus before you remove it, then the bug won't occur.

I'm not sure if it has something to do with the modal window blinking when you click outside of it, or if its purely related to the window not having focus.

Tested using revision 3767, then I updated to 3876 (current at time of writing) and the error still occurs.

[CuteAlien]

Thanks. I wonder if it even makes sense that a modal element can lose the focus completely (meaning neither the element nor it's childs have focus anymore). It's another modal-bug because "modal" isn't part of the element but an own element for some reason (don't know why it was coded like that), but I'll try to find another workaround in the engine for now.

[CuteAlien]

Phew, seemed at first like I would have to change whole focus behavior for this. But once I saw there's a difference between setFocus(0) and removeFocus(0) (the latter resets focus faster and can be called inside focus-change-events therefore) there was an easy workaround. So fixed now in svn release branch 1.7 rev 3885 and as usual trunk will follow soon.

[Reiko]

Thanks for the clarification between setFocus() and removeFocus().

While we're on the topic, would it make sense to call removeFocus(0) too if the element that currently has focus is removed?

Like say I make a window with a button, and when you click it it removes the window. Even though the window (and therefore the button) is gone, getFocus()->getID() will still return the ID of that button.

Or will your change fix this? (still using rev 3876 here). Or is it faster for me to just removeFocus(0) after I've removed the window?

What about gui elements going invisible?

[CuteAlien]

As far as I can see removeFocus always sets the active focus to 0 - and if you pass an element-pointer as parameter and that element has the element it will additionally receive the focus removed event (which then could also again prevent the loss of focus).

Other problems are not fixed with this patch. I know about the problem with focused and hovered elements sometimes still being grabbed after a remove. Only way around that I see currently is users first removing the focus before removing the elements - so yes, you should do a removeFocus(0) before removing the focused element. I'm aware of that problem since a while, but don't know yet how to solve this the best way. Maybe remove doesn't really belong into IGUIElement at all, but there should be instead removeElement in IGUIEnvironment. That way adding and removing would be symetric and the environment could catch whenever that happens. But it's also no 100% solution as with setParent/setChild it's also possible adding elements to the environment. Cleaning up focus in remove() itself (and alos in setParent/setChild) is also not easy as the function is virtual so I have no control over custom implementations.

Maybe I should add something in drawAll that regularly checks if focused and hovered elements are still part of the gui. I don't like that too much as it adds some polling in drawing, but not sure if I find another solution for this.