I have adjusted my bag item icon size and column count so that the bag frame fits exactly to the screen hight while the reagent bag is hidden.

Now, when I click the Reagent Bag Visibility button, the bag frame expands to the bottom, i.e. the lower part of the frame, including the reagents bag and the Reagent Bag Visibility button, goes off-screen.

This is not good, because…

• I clicked the button to see my reagents, but they are off-screen now
• Also the Reagent Bag Visibility button is off-screen, so no toggling back

I could get what I wanted with this:

diff --git a/Baganator/ItemViewCommon/BackpackView.lua b/Baganator/ItemViewCommon/BackpackView.lua
--- a/Baganator/ItemViewCommon/BackpackView.lua
+++ b/Baganator/ItemViewCommon/BackpackView.lua
@@ -24,3 +24,4 @@
   self:SetMovable(true)
   self:SetClampedToScreen(true)
+  self:SetClampRectInsets(0, 0, -1000, 0) -- left, -right, -top, bottom
   self:SetUserPlaced(false)

Same for the bank. This is just to illustrate what I mean, probably not the most proper way.

This one would be best solved with an option to choose the direction to grow the bag, as not everyone wants the bag to grow upwards - I've had a user who wanted it to grow down with the top fixed.

as not everyone wants the bag to grow upwards - I've had a user who wanted it to grow down with the top fixed

My problem was not the general growth direction (if there is enough space). But growing down doesn't make sense IMO when clicking the reagent bag visibility button causes the reagent bag and the reagent bag visibility button to leave the screen.

Edit/PS: It seems that the SetClampRectInsets from my diff does not affect the general growth direction (if there is enough space) at all, it just sets an "escape route" if there is not enough space. (I say "seems" because I have never used that property before.)

This should be resolved in v372 with an option to choose a point to anchor the bag around.

Hm. This doesn't fix it for me.

I loaded 372, without my fix, and it behaves exactly like before. The position of the anchor is respected – but only if there is enough space above and below the frame.

Maybe I'm doing something wrong, or you are misunderstanding what I tried to say.

To reproduce, with the Backpack frame:

1. You are in Single Bag view type., and have a reagent bag.
2. Close the reagent bag.
3. Set the anchor to the bottom (but actually it doesn't matter).
4. Adjust the height of the bag frame via the Bag Columns slider, so that it fills pretty much the whole screen height. It should now be similar to the screenshots (6 bag columns for me):

Screenshot: Top edge of screen

~10px to screen edge; see LDB bar in background

Screenshot: Bottom edge of screen

~10px to screen edge; see LDB bar in background

5. Now click the Regent Bag button to open the reagent bank.

What now happens for me is this (screenshot of bottom screen edge):

The bag grows downwards, pushing the regent bank, including the Reagent Bag button, off screen and thus inaccessible. (Which is the exact opposite of what I want to achieve when I click the Reagent Bag button.)

To actually gain access to the reagent bag, I have to open the Settings now, and increase the number of bag columns. Otherwise I can't even close the reagent bag again.

Now try it with the SetClampRectInsets thingy (see diff in my OP), do the steps as before, and check how it behaves:

When you click the Reagent bag button, the frame now grows upwards, so that you can access your reagents and also close the reagent bag again. (Sure, it pushes the top bar off screen now, but this is not a problem, since it comes back when I close the reagent back again.)

And yes, also with the new anchors system, the SetClampRectInsets thingy does not affect the normal growth behavior. ('normal' = with enough space around the frame).

I have a potential fix in preview:

Baganator-440-5-g9dea26e.zip (edited with updated version)

It adds a scroll bar/scrolling functionality with scroll wheel when the bag exceeds the height of the screen.

Baganator-440-5-g9dea26e.zip (edited with updated version)

I tried to test that, but unfortunately cannot open the bag:

5x ...rfaceBaganator/ViewManagement/Initialize.lua:66: attempt to index upvalue 'backpackView' (a nil value)
[string "@Baganator/ViewManagement/Initialize.lua"]:66: in function <...rfaceBaganator/ViewManagement/Initialize.lua:62>
[string "=[C]"]: in function `ToggleAllBags'
[string "OPENALLBAGS"]:1: in function <[string "OPENALLBAGS"]:1>

Locals:
(*temporary) = nil
(*temporary) = nil
(*temporary) = nil
(*temporary) = nil
(*temporary) = "attempt to index upvalue 'backpackView' (a nil value)"
lastToggleTime = 0
backpackView = nil

It adds a scroll bar/scrolling functionality with scroll wheel when the bag exceeds the height of the screen.

Without having tested it, a scroll bar sounds to me like overkill, because the only way to make the bag exceed the screen height (without manipulating the icon size / column settings) is by expanding the reagents bag. And this case is perfectly covered by the SetClampRectInsets into the correct direction (i.e. not towards the bottom).

Admittedly, I found this function only by accident while vaguely rummaging thru the API in search of something that might serve, and it was never remotely intended as a final solution, but I'm still using it in my working branch, and it does exactly solve the specific problem without causing any interference (at least not with the way I use Baganator) 😊

I can imagine though that a scroll wheel functionality (not a scroll bar) might make some sense in addition to the SetClampRectInsets suggestion (or something equivalent), as it would allow to quickly bring back the top buttons into view if needed without closing the reagents bag.

I'm going to close this issue, as I have no plans to alter the clamp rects, and the scroll bar functionality (as it exists today) should avoid any buttons going offscreen.

Yeah, my last post was from before you actually implemented the scrolling. You are right, the scrolling basically solves the problem, and since it is a more universal solution (also useful in other scenarios), it is certainly the preferable solution.

Sorry for not checking back earlier and closing this.