So I've had time recently to work on an addon and I'm getting stuck with the FauxScrollFrame stuff.
So I'm getting the data to display and it all works if when my data list count is more than or equal to my MAX_ROWS. If my data list count is less than the MAX_ROWS then the entire list doesn't show anymore.
MAX_ROWS is set to 11.
MAX_HEIGHT is set to 20.
function addon:AddFrames()
local frameDesc = "Below is the list of Set Events"
frames.eventsFrame = createFrame("EventEQEvents",gmd,260,276,"TOPLEFT","BOTTOMLEFT",3,4,"EventEQ Events",frameDesc);
frames.scroll = self:CreateScrollFrame(frames.eventsFrame,215,195,10,-65);
frames.rows = self:CreateRows(frames.scroll,210);
scrollUpdate();
end
local function scrollUpdate()
local list = db.events;
FauxScrollFrame_Update(frames.scroll,#list,MAX_ROWS,ROW_HEIGHT)
local offset = FauxScrollFrame_GetOffset(frames.scroll)
for i = 1, MAX_ROWS do
local index = i + offset;
if index < #list then
local b = _G[MODNAME.."ScrollButton"..i];
b.event:SetText(list[index].event);
b.set:SetText(list[index].set)
b.talent:SetText(list[index].talent)
_G[MODNAME.."ScrollButton"..i]:Show();
else
_G[MODNAME.."ScrollButton"..i]:Hide()
end
end
end
function addon:CreateRows(frame,width)
local rows = {};
for i = 1,MAX_ROWS do
local b
if i == 1 then
b = CreateFrame("Button", MODNAME.."ScrollButton"..i, frame)
b:SetPoint("TOPLEFT", 2,-5)
else
b = CreateFrame("Button", MODNAME.."ScrollButton"..i, _G[MODNAME.."ScrollButton"..(i-1)])
b:SetPoint("TOPLEFT", _G[MODNAME.."ScrollButton"..(i-1)], "BOTTOMLEFT", 0, 4)
end
b:SetNormalFontObject("GameFontNormalSmall")
b:RegisterForClicks("RightButtonUp")
b:SetWidth(width)
b:SetHeight(ROW_HEIGHT)
b.index = i;
b:SetScript("OnClick",
function()
table.remove(db.events,b.index);
scrollUpdate();
addon:Print("Deleted!");
end
)
b.event = b:CreateFontString(nil, "ARTWORK", "GameFontHighlightSmall")
b.event:SetPoint("TOPLEFT", b, "TOPLEFT", 0, -6)
b.set = b:CreateFontString(nil, "ARTWORK", "GameFontHighlightSmall")
b.set:SetPoint("TOPLEFT", b.event, "TOPLEFT", 100, 0)
b.talent = b:CreateFontString(nil, "ARTWORK", "GameFontHighlightSmall")
b.talent:SetPoint("TOPLEFT", b.set, "TOPLEFT", 50, 0)
rows[i] = b;
end
return rows;
end
if I'm going about this all wrong please let me know. I've been looking at and reviewing other ppl's addon trying to get a clue on how to do this. But somewhere I'm just missing it and I can't figure this out.
I've also been searching google for examples and not having any luck finding answers there either.
Any advice would be greatly appreciated.
(I would like to stay with lau script for frame creation rather using xml for a solution if that is at all possible)
The problem is you parented the rows to the scroll frame. FauxScrollFrame_Update will hide the scroll frame when appropriate. You should parent the rows to the eventsFrame or change FauxScrollFrame_Update to
Another reason not to use the template! I just code my FSF's by hand, it takes roughly the same amount of code (if not less) as the template, and you're in total control.
It's just a matter of parenting correctly. Even with your own scrollframe implementation, you'd have to parent correctly. The template itself is fine really.
Im looking for addons that have nice implementation of the fauxscrollframe, preferably small addons in order not to spend too much time looking into it :p
Can someone provide some names ?
Great ! It was easier to understand and implement than a real FSF :p
EXACTLY. Effectively it works the same way that the FSF template does... but you don't have to deal with the whole mess of unintuitive API and naming frames that the FSF template has... you just make you rows, save them in a table, make your scroll bar, set it's OnValueChanged (or whatever it was) handler to update the rows, and then set it's value once to trigger that first update. You don't need to track min/max or any of that stuff, you just set the min/max on the scrollbar and let it do the logics.
Only issue is that the scrollbars don't like to stick to exact ints, so you need to round their value off to get a proper int for your table offset.
EXACTLY. Effectively it works the same way that the FSF template does... but you don't have to deal with the whole mess of unintuitive API and naming frames that the FSF template has... you just make you rows, save them in a table, make your scroll bar, set it's OnValueChanged (or whatever it was) handler to update the rows, and then set it's value once to trigger that first update. You don't need to track min/max or any of that stuff, you just set the min/max on the scrollbar and let it do the logics.
I agree. The FSF template really just provides a way for scroll frames to emulate the behavior of a slider. Even Blizzard uses the FSF where a slider would have been more appropriate.
I don't have time to really look into this but from quick inspection tekConfigScroll and FSF are not functionally equivalent...
Let me just mention two things: Mousewheel over parent frame, and auto-hide slider when elements list is shorter than display range.
Really FSF isn't that bad to set up at all, if(!) you want all it does. If you just want a permanent scrollbar(i.e. slider) and/or have unusual needs, then it's worth going it yourself.
And literally the only thing to watch when setting up is parenting. The rest really isn't that hard, or such an odd API. It's literally 4 lines of code to setup and keep updated.
I think the biggest problem with FSF is that, for the longest time, there was nothing in the way of documentation, and very few good examples of its use. It has a lingering reputation of being this obfuscated blob of code that "nobody" knows how to use, or at least, the people who have figured it out have never documented it on [1][2] and whatnot. It's like the secure frame stuff -- the original implementers knew how to use it, and the rest of us were left to reverse engineer it all from scratch.
There is actually documentation of it on wowwiki, but there is a lot of oldschool XML, which doesn't help (http://www.wowwiki.com/Making_a_scrollable_list_using_FauxScrollFrameTemplate). I think conceptually the old http://www.wowinterface.com/forums/showthread.php?t=1104 does help quite a bit. FSF are really just a slider + an invisible "scrollframe", but with all the logic for slider visibility + mousewheel action (via the invisible scrollframe) already set up for a vertial scrolling region. The "scrollframe" really just is a frame that matches the visible area that one expects to scroll and captures the mousewheel and translates it into vertical scrolls. Check out the drawing preserved in that thread. Note that the "child frame" is by no means a necessary or even natural ingredient of FSFs in that drawing though.
Once one realizes what FSF really does it's kinda hard to really see any fluff or real weirdness with the API. It just does what it promises: Place a scrollframe over the area and will handle the vertical slider for the region based on the slider information its provided.
I think the confusion comes from how people expect a scrollframe to work, i.e. that it would handle the elements/frames to be scrolled, which FSF doesn't do and from the fact that it has this invisible frame to capture the mousewheel for scrolling. But that's actually quite clean and makes FSFs considerably flexible. There is some talk even on the wiki when to use FSFs and when sliders which I find not that clear. Ultimately the answer I think is this: If you want mousewheel action for scrolling over the displayed region of scrolled information, and you want out of the box handling of the slider/widgets, use FSFs. If you just want a slider, or explicitly do not want to have mousewheels to be used for scrolling, use a slider.
The basic procedure for using FSFs is simple:
Create the FSF frame.
Match its extensions to the visible region that you (not it) will render.
Add the script for vertical scroll events, these will be both triggered from actions on the slider icons and the mousewheel being turned over the scrollframe. Provide it with your rendering function for the actual visible scroll region and call FSF_OnVerticalScroll() with it to let it know what to call.
Modify any widget textures if you wish.
Within your rendering function get the offset from the FSF to properly render.
If at any point the slider-related info has changed, let FSF know via FSF_Update
Done. This really is about as simple as it gets. Lots of display paradigms use rendering calls like this so the architecture isn't really that unusual.
As for parenting. The slider/scrollframe should be visible with what you attach it to, so parent it to the overall frame containing the scrolled stuff, not the scrolled stuff itself. If the role of the FSF is clear it's quite clear that that is what one has to do.
E.g. if you have a frame that contains a list of scrollable fontstrings, parent your FSF to the frame that is parent to the fontstrings. If you hide the frame, everyhing, including the FSF and all scrollable items (which you control yourself) will be properly hidden. Just the same when if you set this up yourself without FSFs.
So I'm getting the data to display and it all works if when my data list count is more than or equal to my MAX_ROWS. If my data list count is less than the MAX_ROWS then the entire list doesn't show anymore.
MAX_ROWS is set to 11.
MAX_HEIGHT is set to 20.
if I'm going about this all wrong please let me know. I've been looking at and reviewing other ppl's addon trying to get a clue on how to do this. But somewhere I'm just missing it and I can't figure this out.
I've also been searching google for examples and not having any luck finding answers there either.
Any advice would be greatly appreciated.
(I would like to stay with lau script for frame creation rather using xml for a solution if that is at all possible)
Also, in scrollUpdate()
should be
Can someone provide some names ?
Thank you in advance. :p
Ara_Broker_Guild_Friends can now scroll large guilds with little to no additions besides the creation of the slider.
Thank you :)
EXACTLY. Effectively it works the same way that the FSF template does... but you don't have to deal with the whole mess of unintuitive API and naming frames that the FSF template has... you just make you rows, save them in a table, make your scroll bar, set it's OnValueChanged (or whatever it was) handler to update the rows, and then set it's value once to trigger that first update. You don't need to track min/max or any of that stuff, you just set the min/max on the scrollbar and let it do the logics.
Only issue is that the scrollbars don't like to stick to exact ints, so you need to round their value off to get a proper int for your table offset.
I agree. The FSF template really just provides a way for scroll frames to emulate the behavior of a slider. Even Blizzard uses the FSF where a slider would have been more appropriate.
slider:SetValueStep(1) fixes that also
Let me just mention two things: Mousewheel over parent frame, and auto-hide slider when elements list is shorter than display range.
Really FSF isn't that bad to set up at all, if(!) you want all it does. If you just want a permanent scrollbar(i.e. slider) and/or have unusual needs, then it's worth going it yourself.
And literally the only thing to watch when setting up is parenting. The rest really isn't that hard, or such an odd API. It's literally 4 lines of code to setup and keep updated.
Setup:
Update (i.e. here inside Recount.RefreshMainWindow):
I find it fairly hard to consider this all that bad...
[1] http://www.wowwiki.com/World_of_Warcraft_API
[2] http://www.wowwiki.com/Widget_API
Once one realizes what FSF really does it's kinda hard to really see any fluff or real weirdness with the API. It just does what it promises: Place a scrollframe over the area and will handle the vertical slider for the region based on the slider information its provided.
I think the confusion comes from how people expect a scrollframe to work, i.e. that it would handle the elements/frames to be scrolled, which FSF doesn't do and from the fact that it has this invisible frame to capture the mousewheel for scrolling. But that's actually quite clean and makes FSFs considerably flexible. There is some talk even on the wiki when to use FSFs and when sliders which I find not that clear. Ultimately the answer I think is this: If you want mousewheel action for scrolling over the displayed region of scrolled information, and you want out of the box handling of the slider/widgets, use FSFs. If you just want a slider, or explicitly do not want to have mousewheels to be used for scrolling, use a slider.
The basic procedure for using FSFs is simple:
Done. This really is about as simple as it gets. Lots of display paradigms use rendering calls like this so the architecture isn't really that unusual.
As for parenting. The slider/scrollframe should be visible with what you attach it to, so parent it to the overall frame containing the scrolled stuff, not the scrolled stuff itself. If the role of the FSF is clear it's quite clear that that is what one has to do.
E.g. if you have a frame that contains a list of scrollable fontstrings, parent your FSF to the frame that is parent to the fontstrings. If you hide the frame, everyhing, including the FSF and all scrollable items (which you control yourself) will be properly hidden. Just the same when if you set this up yourself without FSFs.
The only downside is requiring your scrollframes to be globally named, but I don't consider than a disadvantage at all.