So, I have two dialogs, both with opaque (alpha 1.0) background color.
They are overlapping and I can read the text of both.
When I opened the new one, and it got input focus at its text field, I was expeting it to completely cover the older one.
This is the older dialog:
When I open the new it gets like this:
I was expecting to see only the new one that should be above, covering the older one:
Any idea how to fix?
Lemur does not automatically change the Z of your dialogs just because they are focusedā¦ it doesnāt even really know that they are dialogs.
You should be able to add a FocusListener to the dialogās GuiControl and then potentially resort the Z order of your dialogs when one gets the focus.
ā¦but either way, Z is what controls what is drawn in front of something else.
This is all presuming I understood the question correctly.
cool thx!
I did exactly that and it worked! I never dealt with GUI dialogs beforeā¦
I consider a ādialogā everything that is directly attached to the gui node.
The only problem I had was that, for the Z order to work, I had to re-add each dialog to the gui node.
I also had to keep track of all focus requests, and on that stack, prioritize the newest requests, so as long there is a dialog enabled, their focus are granted.
Noā¦ the order in the guiNode does not matter. Just the Z value of the local translation. Something else must be going on that I canāt see.
Not sure why you have to keep track of the focus requestsā¦ unless thatās how you are tracking the ādialogsā. You do somehow have to keep track of what you are managing this way so that you can resort them, yesā¦ else you constantly increase Z each time which would work but is a bit hacky.
Indeed I was just trying to deal with the Z-order.
But the Z order only worked after I re-added the dialogs.
If I just modified the Z value, nothing changedā¦
May be I would have to make a minimal test case to understand why I had to re-add to gui node for it to actually work, so I would be sure it was not something I missed to configure/call like some kind of refresh/update for the gui elements.
I had to keep track of the focus because I was modifying the Z of each dialog based on their stack index, so older ones will have the smaller Z values.
And also, when the stack is empty, I have to remove all focus, otherwise it will not āgive focus backā (stop intercepting keys) to the application/game, this also can be something I am missing, as I remove the dialogs from the gui node and initially I thought only that should suffice.
Yeah, could just be a missed state transfer in the GuiControlā¦ not sure it remembers to clear focus if detachedā¦ actually, it occurs to me that it may not even know it has been detached in this case.
Something else was wrong. I adjust things with Z all the time without issueā¦ I sometimes even animate it.
I made some more tests, a Z value of 1000f will make the mouse cursor stop working when trying to click at elements like buttons, even hovering highlight stops working.
I tried that big value to try to avoid removing and re-adding the spatial, but it didnt work, the overlapping still happened. I will see if I can prepare a test caseā¦
So now, I am using a Z displacement of 10f between each dialog, and some of that overlapping problem that was still happening (with a displacement of 0.1f), now are gone!
I mean, it is working great now, despite I quite do not understand why it had to be 10f or more, like it has some kind of precisionā¦ ahhā¦ I guess I am not able to even guess now :), but it is working great, is what matters!
0.1f might have been too small because of the layers in the components themselves. Many of them have thickness already. 1 should have been fine, though.
As for the 1000 thingā¦ could be that I hard-coded my picking rays to that height. Oops. Iāll have to look.