What steps will reproduce the problem?
1. Using :SetCell(...) with an column span > 1
2. Using long texts for the spanned cell and avoid using cells without column span > 1 will emphasize the effect
3. If the width of the spanned cell is less than the total with of unspanned cells in another line the effect can't be observed.
What is the expected output? What do you see instead?
When displayed the content is shown in a single line, but the height is much bigger than a single line would require.
Instead the height seems like what it would be like if the content had been wrapped around.
What version of the product are you using?
Appears in all revisions r136 and up.
Please provide any additional information below.
Release r136 replaced the width handling for colspans: function LayoutColspans(tooltip) with function FixCellSizes(tooltip).
I found that cell:getContentHeight() returned the same value after the resizing of the columns. This is because the actual cell width used in function getContentHeight() never got touched. As far as I can see it the cell size is nowhere set at all but the calculations depend on column width values alone.
So I think you either need to adjust the cell width values to their actual values so the fontstring width is set correctly so it returns the correct fontstring height.
Or (since the whole point of the resizing is to fit the content of the cell in one line) you just continue to recalculate the line height values with cell.fontstring:GetStringHeight():
for _, line in ipairs(lines) do
if #(line.cells) > 0 then
local lineheight = 0
for _, cell in pairs(line.cells) do
if cell and cell.fontstring then
lineheight = max(lineheight, cell.fontstring:GetStringHeight())
if lineheight > 0 then
ResizeLine(tooltip, line, lineheight)
I haven't looked into it in detail, yet, but the code you suggest has one major flow: it assumes that only the default cell provider is being used since it accesses internas of a cell that are assumed to be unknown to the library itself (even though the default cell provider is provided by the library).
With regard to the cell width, this value is implicitly generated via the column frames the cell is anchored to. Actually I implemented that delayed recalculation of cell size to prevent the bug you describe since I had it without that code... strange...
in the getContentHeight() function, changing local height = self.fontString:GetHeight() to local height = self:GetHeight() leads to the preferred behavior. Not sure if that's what you want or not, lol. In :SetupCell() you use fs:GetHeight() so it's probably just a coincidence.
@@ -292,7 +292,7 @@
local fs = self.fontString
fs:SetWidth(self:GetWidth() - (self._paddingL + self._paddingR))
- local height = self.fontString:GetHeight()
+ local height = self:GetHeight()
The problem is it is calculating for wrap that doesn't happen. GetStringHeight does account for wrapped lines, the reason the code above works (using fontString) is because the width isn't set.
There's just something wonky with how LibQTip sets the width, because it's not corresponding to the width used in labelPrototype:SetupCell or labelPrototype:getContentHeight to get the font string height ;[ Even using maxWidth in :SetCell doesn't work properly.
I'm using it in ElkGuild with a maxWidth of 0 (at least local) and it's working fine :/
Without setting maxWidth and minWidth on all of the columns, my tooltips tend to go batshit crazy
Simple example: http://i.imgur.com/lBe1w.jpg
Any I wrong to think that a column should expand to its maxWidth without increasing the height and never be wider than its maxWidth? Could very well just be doing this wrong.
Definitely seeing this issue myself. I'll try to set sizes specifically and see if that works.
Well, fontstring size is strange stuff :/
see: http://www.wowpedia.org/UIOBJECT_FontString (though that info could be outdated)
In your testcase I think one of the problems is that the width of column 2-4 is defined by a colspan and not a single column but not sure... I'll try to run some more tests myself again...
maybe go with only a topleft anchor for the fontstring or such...
I still believe that the basic logic I implemented works fine meaning that you can only calculate the line height after you fixed the column width for colspans that don't have enough width, yet. Only the return values for the width/height functions seem to mess that up.
Everything appears to work ok if you also have individual columns with proper content. If, however, you only have colspan-enabled cells, things get all wonky.
Ok so I had this issue even without colspan and I figured out how to fix it. After setting up my tooltip a call like this fixes my layout problems:
Perhaps this could be done automatically somehow, like on :Show() or :SmartAnchorTo() or both?
tooltip:UpdateScrolling() has a bad side effect when you're using SetPoint to move the tooltip around. In my particular case tooltip:GetTop() was returning nil, which is used in tooltip:UpdateScrolling().
I've been playing with this and it reminds me of an issue in LCD4WoW where fontstrings would expand in width as text characters scrolled from cell to cell. The solution to that was to set the maximum width per cell.
I think this is simply a WoW UI bug. Even if it's not, I think the best route is to give users the ability to set maximum height. It's the best solution I can think of. I can't figure out why fs:GetHeight() is returning such a high number sometimes; the text never changes! I know I'm not as seasoned as other WoW addon authors around here, but after digging into this thing with everything I could think of I think this bug is an "infinite loop" reaching the same conclusion over and over; the only "break condition" I can see is in the user's option to restrict such spurious behavior. >.<
To post a comment, please
or register a new account.