Support #7454

Popup in layout-based design

Added by Marco Kinski almost 3 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


I am using layout-based design and have composed a SuggestionPopup like widget.

After updating from Wt 4.1.2 to 4.2.1 the popup is rendered inside the scrollarea (expanding the scrollbars).

Is there a way to reenable the "wt-no-reparent" (style-class) workaround or an alternative solution?

(attached code is a reduced snippet)


main.cpp (3.74 KB) main.cpp Marco Kinski, 02/11/2020 01:22 PM
PopupMenuHidenUnderScrollbar-1.PNG (5.13 KB) PopupMenuHidenUnderScrollbar-1.PNG Marco Kinski, 02/24/2020 03:10 PM
PopupMenuHidenUnderScrollbar-2.PNG (6.66 KB) PopupMenuHidenUnderScrollbar-2.PNG Marco Kinski, 02/24/2020 03:10 PM
main.cpp (4.13 KB) main.cpp WPopupMenu on dialog Marco Kinski, 02/24/2020 03:10 PM

Updated by Marco Kinski almost 3 years ago

Almost same problem happens when using WPopupMenu on a button.


Updated by Roel Standaert almost 3 years ago

Yeah, this the result of the reparenting working as intended. That's where it's supposed to end up so that it scrolls along, but it appears that indeed not everyone agrees on what should happen there.


Updated by Marco Kinski over 2 years ago

A invisible "popup" because its placed inside a scrolling container. I don't know a scenario where this is intended.


Updated by Roel Standaert over 2 years ago

Yeah, it's not so much the being hidden part, it's the scrolling along part that's intended. So that if you have a popup open and you scroll it, it stays attached to the widget it belongs to. That creates the nasty side effect of being hidden. I've seen desktop UIs just close the popup automatically when you scroll, so maybe that's just the route we should take with that? Alternatively, we'd have to keep tracking the widget that it belongs to and make sure the popup stays attached as you scroll.

Also available in: Atom PDF