Jump to content

Menubar items cut off by scrollbox


photo

Recommended Posts

I put a <scrollbox height="40"> around the <menubar> in professional_windows_2.6.1_src/source/samples/Api/Widgets/UserInterface/data/user_interface.ui and the menus no longer sit on top of the rest of the UI. Is this a bug, or is there something else I need to do to make menus work from within a scrollbox? 

image.png

Link to comment

Putting a <groupbox> around the <menubar> gives an even worse result.

image.png.5bd9829c52190467fd7f3fe22ae7daf7.png


Personally, I would expect a dropdown menu to always render over the top of the rest of the UI.

Link to comment

Hi Greg,

Unfortunately, there is no easy fix available. Currently engine widgets have no correct Z-ordering mechanism, so in order to achieve what you want you will have to implement it first. Another solution will be to use Qt or 3rd party GUI libraries (like CoherentGT or NoesisGUI).

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment
  • 1 month later...

We didn't have time to follow this up so we just had to accept releasing our prototype this bug. Now I've got time to ask again: where is the order fixed?

Link to comment

Hello Greg,

Widgets z-ordering is determined by hierarchy and there's no overriding mechanism. That's why moving menu bar down by the hierarchy affects its z-order.

Link to comment

I don't think it can be the tabbox drawing over it, because the menu draws over the tabbox just fine if I don't add the scrollbox.

And it definitely _looks_ like it's the bottom of the scrollbox cutting off the menubar, not the top of the tabbox.

So... any other explanation?

Link to comment

Yes, you're right, scrollbox seems to crop menubox. But even if it wouldn't that doesn't fix the problem. There's still z-ordering issue that can be seen on the second screenshot with groupbox.

Link to comment

OK good, that's progress. Now we know there are two problems to solve.

Is scrollbox-cropping-menubox a bug that you're likely to be able to find a patch for?

In the meantime I'll try to get the z-ordering the way I want it. If it's just based on hierarchy then that's good, because the two widgets are cousins, neither is a direct descendant of the other. So somewhere there is a pair of sibling widgets (added to the same container) that are the ancestors of each. How is the ordering between those two sibling widgets defined? Can I just add them to the container in the opposite order (maybe using opposite alignment too?) to make them draw in the opposite order?

Link to comment
  • 1 month later...

Sorry it's taken me a while to get to this. That patch does fix the sample code. When I tried to put the scrollbox we wanted back into our main codebase, I found that it was looking a little different these days and although the patch is _probably_ doing its job,  the behaviour is being obscured by an even stranger problem.

It's once again very easy to demonstrate by slightly modifying user_interface.ui: after adding the <scrollbox> described in my first post, put a gridbox containing a menubox directly inside the new scrollbox:


    <gridbox columns="2">
      <menubox>
        <text>a</text>
      </menubox>
    </gridbox>

 You will see that the menubox is only visible when the mouse is hovering over the scrollbox. Do you have any explanation or workaround for this?

It might just be a secondary symptom, but if I add enough menuboxes to make the scrollbox need to actually scroll, then I can scroll the menuboxes to make them display outside of the scrollbox as if they were ALIGN_OVERLAP. (they don't overlap the title bar above or tabbox below, so I doubt the patch is to blame)

Edited by Greg.Mildenhall
Link to comment
×
×
  • Create New...