TextBuffer:GetNumHistoryLines yet another buggy API

Fathis Ules · 04/27/14, 04:18 AM

In WoW and GetNumMessages() when you write a long line and if that line is wrapped, taking the space of 3 lines for example, GetNumMessages() will return 3

In Eso and GetNumHistoryLines() when you write a long line and if that line is wrapped, taking the space of 3 lines for example, GetNumHistoryLines will return 1

How is this weakness possible today !

thelegendaryof · 04/27/14, 05:12 AM

Its technically correct how ESO handles it - after all the textbox width isnt fixed in ESO. Technically its still a single line and not 3 no matter how its displayed for the user. If you really need to get the displayed dimensions you will just have to calculate them yourself and write a similiar function to what WoW has.

Its by no means bugged - its working as intended.

Fathis Ules · 04/27/14, 05:35 AM

You don't see it bugged because you don't make use of it

Even when the devs uses it, they have it also buggy because when they write

Lua Code:

function ChatContainer:UpdateScrollVisibility()
    local visible = self.currentBuffer:GetNumVisibleLines()
    local history = self.currentBuffer:GetNumHistoryLines()
    local hide = history <= visible
 
 
self.scrollbar:SetHidden(hide)
self.scrollUpButton:SetHidden(hide)
self.scrollDownButton:SetHidden(hide)
self.scrollEndButton:SetHidden(hide)
end

You will notice the visibility of the slider update perfectly if no lines are wrapped, but as soon as you have many wrapped lines, the slider will be hidden when it should be visible or vice versa

The same code the devs are using works perfectly in Wow because the GetNumHistoryLines() is very well implemented under wow

In Eso they just workaround this weakness by adding a larger value to the slider bar so you can slide at a larger value than what is inside the textbuffer but that's just an ugly workaround they made

thelegendaryof · 04/27/14, 06:05 AM

Well then its indeed wrongly implemented (not technically bugged) in that case - keep in mind this isnt WoW but a completely other Software - they're just both using Lua and Eso might have been inspired (to whatever dimension) but it is not a 1:1 copy of the WoW-API. Thats especially true for any UI related functionality.

I cant check the behavior myself right now, as I dont have access to a PC atm (I'm writing from my Phone). But there are a few different solutions to that kind of missbehavior. Hack the ChatWindow and correctly calculate the visible Lines for yourself with your own function - that is the most "solid" solution which probably wont break anything else. Another would be hooking / overwriting the global GetNumHistoryLines - which is bound to break many stuff - as you dont know how its functionality is intended by the Developers and last but not least contact the Support/Developers and ask them how its intended to work, and that you found that its implementation in the ChatWindow isnt correctly taking the visible line dimension into consideration and as such leads to a to early/late display of the scrollbar.

All in itself its however pretty useless to complain about it here. Either find a solution for yourself or contact the developers / support like I've written in detail above.

Cheers

Fathis Ules · 04/27/14, 06:22 AM

At least the issue is search friendly, not really the case with the official forums, submitted it in /bug but I believe it has more chance to be seen here by a ui designer than on the official forums or even in /bug huhu

Kentarii · 05/13/14, 05:50 AM

I noticed the shortcomings of these functions when I tried to implement a function to scroll the first line of my textbuffer to the top of the control. Worked fine as long as lines weren't wrapped.. not so much when multiple lines wrapped.

By default, scrolling the textbuffer to the top means that your first line is at the bottom, showing only one line, thus leaving a lot of blank space a the top.

thelegendaryof · 05/20/14, 06:30 AM

I implemented an own solution in my EditBuffer component that basically uses the EditControl to generate virtual lines like the TextBufferControl but is instead able to correctly calculate the Line-Width due to using a Monospace-Font unlike the native one. See here for how I did it:

http://www.esoui.com/forums/showthread.php?t=1538

SplitLongLines() is what you're seeking for.