ZO_ScrollList issue - scroll bar not appearing

merlight · 02/10/15, 08:16 AM

So I have a ZO_ScrollList and put ZO_SelectableLabel rows in it.

list:GetHeight() == 677
list.contents:GetHeight() == 677
list.controlHeight == 28
each label's height is 28

677 / 28 == 24.178571428571427 ... which means 24 labels fit without scrolling.

If there are 25 labels in the list, scroll bar doesn't appear, and the last label is partially visible (that's 0.17857 of its height).

If there are 26 labels, scroll bar does appear and work, but...
Thumb texture doesn't fit between Up/Down buttons. Button height is 16, so maximum allowable thumb height should be 677-2*16 = 645 (which happens to be exactly list.scrollbar:GetHeight()), but its actual height is 666.96838378906 and thus runs beyond the buttons!

If there are 27 labels, everything looks okay.

Did I do something stupid, or is there a bug in ZO_ScrollList?

edit: doing it on PTS

circonian · 02/10/15, 03:41 PM

PTS said it was down for maintanence so I couldn't log in to test there. I've not had that problem on the normal server though.

Here are some ideas I had to look at, but the first thing I would check is if:

Lua Code:

ZO_ScrollList_GetHeight(self)
 
-- matches
self:GetHeight()

Do those match? I'm guessing they don't. Because your basing your calculations on scrollList:GetHeight(), but that is only used if scrollList.windowHeight is nil, the game code calls this to get the window height to use in the scrollDistance calculations when you commit your data to the scrollList:

Lua Code:

function ZO_ScrollList_GetHeight(self)
    if(self.windowHeight) then
        return self.windowHeight
    else
        return self:GetHeight()
    end    
end

If that doesn't help here are some other ideas

Are your row controls set to the same height as the buttons when you add the data to the scroll List?

Lua Code:

-- does this button height:
local BUTTON_HEIGHT = 50
ZO_ScrollList_AddDataType(self.scrollList, ROW_TYPE_ID, "WayPointButton", BUTTON_HEIGHT, setupCallback)

Xml Code:

<Control name="WayPointButton" virtual="true" clampedToScreen="false" mouseEnabled="true" movable="false" hidden="false" layer="2" level="0" tier="0" allowBringToTop="true" alpha="1" >
 
<!-- Match the height of your rowControl: -->
   <Dimensions x="300" y="50" />
...

When you add the data are you using the same (correct) ROW_TYPE_ID

Lua Code:

local entry = ZO_ScrollList_CreateDataEntry(ROW_TYPE_ID, rowData, 1)

Is the scrollList.mode:

Lua Code:

SCROLL_LIST_UNIFORM = 1
SCROLL_LIST_NON_UNIFORM = 2

That changes how the scrollableDistance is calculated, if its set wrong that might cause the problem.

if its SCROLL_LIST_NON_UNIFORM

Lua Code:

local windowHeight = ZO_ScrollList_GetHeight(self)
scrollableDistance = currentY - windowHeight

Where currentY is the bottom of the last data row.

But if its SCROLL_LIST_UNIFORM

Lua Code:

local windowHeight = ZO_ScrollList_GetHeight(self)
scrollableDistance = (#self.data) * self.controlHeight - windowHeight

Then when you commit the data to the scrollList it should be calling:

Lua Code:

function ZO_ScrollList_Commit(self)
-- which calls
local function ResizeScrollBar(self, scrollableDistance)

Which resets the thumb texture height based on those values

Lua Code:

if(scrollableDistance > 0) then 
   ...
   self.scrollbar:SetThumbTextureHeight(scrollBarHeight * scrollListHeight /(scrollableDistance + scrollListHeight))
   ...
else
   ...
   self.scrollbar:SetThumbTextureHeight(scrollBarHeight)
   ...
end

merlight · 02/10/15, 04:53 PM

After I was interrupted by maintenance on the PTS, I went to live and experienced the same issue. I tried doing the calculations in ResizeScrollBar by hand, and got correct results. Then with some hooks I found out that by the time I filled the list and called ZO_ScrollList_Commit, list:GetHeight() was 713 and list.scrollbar:GetHeight() was 681. I have no idea why, but feeding these numbers into ResizeScrollBar, you get 667.

Then there was a second ZO_ScrollList_Commit call, which wasn't coming from my code, but from OnContentsUpdate. According to ZOS comments, it's a deferred commit until after anchors were processed. But the heights were still 713 and 681.

Then, looking at the broken scrollbar ingame, I tried /script ZO_ScrollList_Commit(list) ... and it fixed itself. list:GetHeight() was 677 and list.scrollbar:GetHeight() was 645.

Conclusion: I probably called ZO_ScrollList_Commit in some intermediate state where the list already had non-zero height, but it was not final as not all anchors had been processed yet. I didn't set the height directly - the list had TOPLEFT anchored to one control, and BOTTOMRIGHT to another. And although I don't move any of the involved controls around after construction, somehow it doesn't get the correct height immediately. I guess it'll be safest to ZO_ScrollList_SetHeight explicitly to avoid any issues.

circonian · 02/10/15, 07:07 PM

Originally Posted by merlight

After I was interrupted by maintenance on the PTS, I went to live and experienced the same issue. I tried doing the calculations in ResizeScrollBar by hand, and got correct results. Then with some hooks I found out that by the time I filled the list and called ZO_ScrollList_Commit, list:GetHeight() was 713 and list.scrollbar:GetHeight() was 681. I have no idea why, but feeding these numbers into ResizeScrollBar, you get 667.

618 + 2*16 = 713 -- it leaves room for the UP/DOWN scroll buttons

Originally Posted by merlight

Then there was a second ZO_ScrollList_Commit call, which wasn't coming from my code, but from OnContentsUpdate. According to ZOS comments, it's a deferred commit until after anchors were processed. But the heights were still 713 and 681.

If you had your anchors set the second commit was probably comming from when you added your data type. Everytime you add a new dataType this also calls ZO_ScrollList_Commit.

Lua Code:

function ZO_ScrollList_AddDataType(self, typeId, templateName, height, setupCallback, hideCallback, dataTypeSelectSound, resetControlCallback)

Originally Posted by merlight

Conclusion: I probably called ZO_ScrollList_Commit in some intermediate state where the list already had non-zero height, but it was not final as not all anchors had been processed yet. I didn't set the height directly - the list had TOPLEFT anchored to one control, and BOTTOMRIGHT to another. And although I don't move any of the involved controls around after construction, somehow it doesn't get the correct height immediately. I guess it'll be safest to ZO_ScrollList_SetHeight explicitly to avoid any issues.

One of my scrollLists is set up just like yours it sounds, with both corners anchored & as soon as I dump the data in I call ZO_ScrollList_Commit on the next line without any delay. Mine doesn't have any problems like that though.

Are the controls you anchored it to from an addon? Any chance they moved or changed size which would have changed the placement of your anchors & changed the size of your scrollList ? Especially if one of those controls has something like ResizeToFitXXXX() and its contents or padding changed. Or someone set dimensions/position in XML, then reset it in lua and changed it by a small amount. It wouldn't take much of a change, those numbers aren't off by much.

merlight · 02/11/15, 08:01 AM

The layout is all newly created controls, like this:
TopLevelWindow - fixed width, height, no resizeToFit
+ Backgrounds - fixed dimensions, anchored to TLW and excludeFromResizeToFit (just to be sure)
+ Title - fixed height, anchor (TOPLEFT, TLW, TOPLEFT)
+ Divider - fixed height, anchor (TOPLEFT, Title, BOTTOMLEFT)
+ List - anchor (TOPLEFT, Divider, BOTTOMLEFT) anchor (BOTTOMRIGHT, TLW, BOTTOMLEFT, 250, -120)

So the second List anchor determines its width and height. The TLW is anchored by ZO_ReanchorControlForLeftSidePanel.
I still can't see why the List had one height after creation, and another when it was shown. I replaced the second anchor with fixed width and height, and the scrollbar appears correctly.

circonian · 02/11/15, 07:15 PM

Originally Posted by merlight

The layout is all newly created controls, like this:
TopLevelWindow - fixed width, height, no resizeToFit
+ Backgrounds - fixed dimensions, anchored to TLW and excludeFromResizeToFit (just to be sure)
+ Title - fixed height, anchor (TOPLEFT, TLW, TOPLEFT)
+ Divider - fixed height, anchor (TOPLEFT, Title, BOTTOMLEFT)
+ List - anchor (TOPLEFT, Divider, BOTTOMLEFT) anchor (BOTTOMRIGHT, TLW, BOTTOMLEFT, 250, -120)

So the second List anchor determines its width and height. The TLW is anchored by ZO_ReanchorControlForLeftSidePanel.
I still can't see why the List had one height after creation, and another when it was shown. I replaced the second anchor with fixed width and height, and the scrollbar appears correctly.

offsetY = -120

Lua Code:

+ List - anchor (TOPLEFT, Divider, BOTTOMLEFT) anchor (BOTTOMRIGHT, TLW, BOTTOMLEFT, 250, -120)

What are those other fixed dimensions? My guess at this point would be that if it had 1 height, that is all of the room there was. Is your TLW height 120+1+titleHeight+dividerHeight (-OffsetY distance + the 1 you said the list had a height of 1 + title height + divider height)?

EDIT:
One other long shot, I'm not sure if this would even happen, but its the only other thing I can think of.
You said your anchoring the TLW by passing it to:

Lua Code:

function ZO_ReanchorControlForLeftSidePanel(control)

Which clears the anchors & sets a new TOPLEFT anchor and registers it for EVENT_SCREEN_RESIZED to reset that anchor on that event.
Any chance some code, yours or the games, could be running while all of the anchors are getting moved which might temporarily mess up the calculations?
Have you tried anchoring the TLW manually to a fixed position (so no anchors move) and see what happens?

I know you said you got it to work a different way, but if you want to post some code I'll look at it, give it a try, & see what happens.

merlight · 02/12/15, 04:07 PM

Yesterday I spent a lot of time struggling with row selection (lesson learned: never ZO_ScrollList_SelectData between Clear and Commit).

But back to the scrollbar issue. It sure has something to do with anchors. ZO_Reanchor* is not causing it, I replaced that with just :SetAnchor and the issue persists. And it only happens if I define the anchor early after creation -- if I defer that until just before the window is shown, scrollbar is fine.

Here's my extracted sample to reproduce the issue. It defines some globals prefixed LAMSoundList*, hopefully they don't conflict with anything.
https://gist.github.com/merlight/d2f...list_issue-lua

Go to Settings, there will be a new entry SOUNDS.

In populateSoundList, 26 rows are added, but I can only see 25, and the scrollbar spills beyond its buttons. It might depend on screen resolution, I have 1920x1080.

If the scroll bar is broken, try /fixlist command, it will call ZO_ScrollList_Commit and should fix it.

circonian · 02/13/15, 01:58 AM

Heres the problem.

You did not set dimensions on your Title control, but your divider is anchored to it & the scrollList is anchored to it.
Your Title controls BOTTOMLEFT is the same as its TOPLEFT (it has no height, YET) which causes the anchors to change later.

Lua Code:

divider:SetAnchor(TOPLEFT, title, BOTTOMLEFT, 0, 2) 
list:SetAnchor(TOPLEFT, divider, BOTTOMLEFT, 0, 5)

The text control has 0 height until you add text because you did not :SetDimensions on it. When you add text to it, it changes the height, thus changes the BOTTOMLEFT anchor point and therefore moves the divider & resizes the scrollList.

You set the text RIGHT BEFORE you populate the list which calls commit to quickly and does calculations on the wrong values.

Lua Code:

function PRIVATE.init()
    ...
     
    function panelData.callback()
        ...
        -- This is the first time you've set
        -- the text, the Title control has 0 height
        title:SetText(panelName)
         
        if not listPopulated then
-- when you call this it does calculations on the wrong values
-- because all of the anchors have not updated yet
-- It doesn't take much time, wrapping it in a zo_callLater with 
-- a delay of only 1 even solved the problem.
            PRIVATE.populateSoundList(tlw:GetNamedChild("SoundList"))
            listPopulated = true
        end
    end
     
    ...
end

Just :SetDimensions on your title control.

Lua Code:

function PRIVATE.createSoundsWindow()
    ...
    
    local title = wm:CreateControl("$(parent)Title", tlw, CT_LABEL)
    title:SetAnchor(TOPLEFT, nil, TOPLEFT, 65, 70)
    title:SetFont("ZoFontWinH1")
    title:SetModifyTextType(MODIFY_TEXT_TYPE_UPPERCASE)
    
    -- Just set dimensions & it will be ok
    title:SetDimensions(300, 50)
    -- Or Add dummy text to fix the height:
    title:SetText("Dummy Title to Fix Height")
    -- But thats probably asking for some other 
    -- problem to creep in.
    ...
end

I would also change it and anchor the scrollList directly to the TLW...or at least anchor both the TOPLEFT & BOTTOMRIGHT to the same control so you don't have to worry about something moving/changing causing the list to resize again & having to try and track all of those changes through multiple controls again.

merlight · 02/13/15, 06:17 AM

Originally Posted by circonian

The text control has 0 height until you add text because you did not :SetDimensions on it. When you add text to it, it changes the height, thus changes the BOTTOMLEFT anchor point and therefore moves the divider & resizes the scrollList.

You've seriously blown my mind. So obvious, yet I wouldn't have figured that out in a million years!

Originally Posted by circonian

I would also change it and anchor the scrollList directly to the TLW...or at least anchor both the TOPLEFT & BOTTOMRIGHT to the same control so you don't have to worry about something moving/changing causing the list to resize again & having to try and track all of those changes through multiple controls again.

Yea I will do that. Thanks.