FS#6060 - Allow drawing dropdown lists with scrollbars above the widgets

Attached to Project: OpenTTD
Opened by Juanjo (juanjo) - Saturday, 12 July 2014, 14:56 GMT
Last edited by frosch (frosch) - Wednesday, 16 July 2014, 20:31 GMT
Type Patch
Category Core
Status New
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


Currently dropdown lists are put above or below the widget:
1) If there is enough space below the widget that opens the list, draw it below.
2) Else, if there is enough space above the widget, draw it above.
3) Finally, if the complete list cannot be drawn because there isn't enough space, draw it below with a scrollbar.

Moreover, if 1 and 2 fails, and there is not enough space to draw at least one item below the widget, the next assert is triggered (in a not-too-close point of the code):
Assertion failed at line 688 of .../src/widgets/../widget_type.h: capacity > 0

The patch tries to change the procedure for choosing a place to draw the list:
1) If there is enough space below the widget that opens the list, draw it below.
2b) Else, check where is more space available and see if a scrollbar is needed.
3b) Before continuing, if there is no space for drawing a single item, stop with an assert(). (Could be changed to show an alert or debug message or to return without drawing the list).

This way, it is possible to draw a dropdown list with a scrollbar above the widget. In addition, if the list cannot be shown, an assert is triggered as well, but in a place where it is easier to understand the problem.

There are several changes on names of variables:

+int available_height = GetMainViewBottom() - top - 4;
so the expression "top + height + 4 >= GetMainViewBottom()" becomes "height >= available_height".

+int available_height_above = w->top + - GetMainViewTop() - 4;
so the expression "w->top + - height > GetMainViewTop()" becomes "available_height_above > height".

The expression "screen_bottom - 4 - top" becomes "available_height".
This task depends upon

Comment by Juanjo (juanjo) - Saturday, 12 July 2014, 14:56 GMT
The task is a patch, not a bug...
Comment by frosch (frosch) - Wednesday, 16 July 2014, 20:30 GMT
It's funny how the dropdown starts scrolling downwards when opening it and holding down the mouse button. I wasn't even aware that it scrolled at borders like that.

Maybe it can be fooled by opening the dropdown scrolled to the very bottom, when opening it towards the top.
Comment by Juanjo (juanjo) - Thursday, 17 July 2014, 12:36 GMT
I added 4 final lines to do as frosch said. The trick is the same used when opening the dropdown with scrollbar below the widget, which opened the dropdown scrolled to the top position by default.
Comment by Juanjo (juanjo) - Saturday, 01 April 2017, 23:30 GMT
With the recent changes in r27820, if a dropdown is opened above the parent widget and with a scrollbar, as frosch commented, it starts scrolling downwards.
The next patch can be applied to r27837.