Lemur overlapping dialogs are getting mixed, how to fix?

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.

1 Like

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.

1 Like

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.

1 Like