confirm: order-remove: work around stale scroll position

The scroll_position_work_orders value is being used here as the index of
the first displayed order. DF seems to maintain this when the list view
is updated via scrolling, but DF does not update it in at least two
important situations:

- when an order is removed, and
- when the order list view grows enough to display additional orders
  (e.g., by increasing the height of the DF window).

When the order list view is not scrolled all the way to the bottom, DF
handles these actions by pushing orders into view at the bottom of the
list view. Since the same order is still at the top of the list view,
this does not require an update of the reported scroll position value.

However, when the order list view is scrolled all the way to the bottom,
DF handles these actions by pushing orders into view at the *top* of the
list view. Since a new order is now at the top of the list view, we
would expect that DF should have updated the reported scroll position,
but it does not. The lack of scroll position update breaks our
expectation that the reported scroll position should match the index of
the first displayed order.

If N orders have been removed and M order rows have been added to the
order list view (after having scrolled to the bottom of the order list),
our calculated order_idx will be N+M too high (causing mismatched
descriptions in the confirmation dialogs, and out-of-bounds errors that
entirely prevent confirmation when acting on the last N+M orders!).

When there are at least as many orders as the height of the orders list
view, DF seems to always keep the bottom of the list view populated.
Assume this is will be case and adjust our order_idx calculation when
the reported scroll position would put the effective index of the last
order out of bounds.

If DF's order list view ever changes to displaying empty order rows even
when there are orders that could be "pushed in" from the top, this will
need to be revisited.

Author: ChrisJohnsen

changelog.txt

@@ -40,6 +40,7 @@ Template for new versions:
 - `confirm`: only show pause option for pausable confirmations
 - `confirm`: when editing a uniform, confirm discard of changes when exiting with Escape
 - `confirm`: when removing a manager order, show correct order description when using non-100% interface setting
+- `confirm`: when removing a manager order, show correct order description after prior order removal or window resize (when scrolled to bottom of order list)
 
 ## Misc Improvements
 

internal/confirm/specs.lua

@@ -458,7 +458,16 @@ ConfirmSpec{
     message=function()
         local order_desc = ''
         local scroll_pos = mi.info.work_orders.scroll_position_work_orders
-        local y_offset = gui.get_interface_rect().width > 154 and 8 or 10
+        local ir = gui.get_interface_rect()
+        local y_offset = ir.width > 154 and 8 or 10
+        local order_rows = (ir.height - y_offset - 9) // 3
+        local max_scroll_pos = math.max(0, #orders - order_rows) -- DF keeps list view "full" (no empty rows at bottom), if possible
+        if scroll_pos > max_scroll_pos then
+            -- sometimes, DF does not adjust scroll_position_work_orders (when
+            -- scrolled to bottom: order removed, or list view height grew);
+            -- compensate to keep order_idx in sync (and in bounds)
+            scroll_pos = max_scroll_pos
+        end
         local _, y = dfhack.screen.getMousePos()
         if y then
             local order_idx = scroll_pos + (y - y_offset) // 3