Good to know, thanks. That's not obvious from the documentation. Perhaps you could include Refresh on the API page, and mention the above on the SetData page?
edit: actually, Refresh doesn't draw anything; SortData draws the table (but seems a misnomer since I'm not sorting by any field ever).
Right... well... because of the way sorting works ( it doesn't actually sort your table, it makes a sort-reference table ) You must call it when the data changes... I think refresh used to work back before I made sorting... it's been a while. I know you don't sort... but if you add data to the table I don't think you'll get the needed references in the sort table... that might be something I could fix... I'll have to think about that one. In the mean time, just call SortData after each addition ( or group of additions, if possible )
It looks like I could also use the DoCellUpdate member, maybe, but clicking on the link at http://www.wowace.com/addons/lib-st/pages/set-data/ for "DoCellUpdate" gets me a 403 error. I think I'm figuring it out from the Core.lua code though.
I fixed the link. I did have a page for DoCellUpdate. There's not a TON of information about it yet, but I did have a page, the link was just broken :)
The bad news is using |t is terrible. There's padding that I couldn't seem to control around the icons.. and it just ended up looking bad...
The good news is providing a custom DoCellUpdate function isn't too bad, and lets you position textures perfectly. See this link. On the right hand side with the gear icons is a lib-st table. The icon cells also have a hover-over for displaying a tooltip.
(1) I was surprised that there is no "AddRow"-type function. It could simply take a table representing another ("row object" as SetData calls them), insert it into the larger .data table, and go through the same refresh/resort routine as the major SetData does.
This isn't going to be a problem for my addon, since I'm maintaining an external "real" version of the data table. As the data expands every few minutes, I append another row object and then re-call SetData passing in the same table.
(2) There's going to be a lot of garbage collection churn, and that's just with lib-st, not the widget wrapper. There are improvements that could be made but would require nontrivial changes to lib-st, so I'm trying to avoid thinking about that until the larger project is finished. :-) There might be a suggested patch emerging out of this, or maybe not, depending on caffeine and motivation levels!
All told, lib-st beats the hell out of anything I could have done by hand.
you shouldnt need to setdata with the same table. just appending the data to your data table backend... resorting or calling refresh should do the rest.
Where will the garbage churn be around? I've put in some fixes for unneeded table creation, can you point out any other places?
Interesting. I'm very interested to see what you come up with. I've been hesitant to dig too deep into this as I've been on a leave from wow, but still popping in to support guildies who use the dkp mod that uses this lib.
I've also been worried that the structure of lib-st does not follow any of the AceGUI conventions... and a rewrite would be hefty. I hope you find the lib useful and easy to work with.
I came across this library and would like to play a little bit with it but some things seem weird to me :
1/ the way you seem to use it in your DKP addon is by not embedding it (I guess you have a standalone version), any particular reason ?
2/ I have very specific needs, I'm trying to display reports that have a varying number of lines AND columns, does that mean that I should recreate a new instance each time I want to change the columns ?
You'd have to reset the column information and data information.... It might not be worth it. Try it out though and let me know if you run into problems.
basically, that makes the old system of "onclick" work with the new system without any changes. plus, it lets you register a single "onclick" function at the column header level (the argument to SetDisplayCols) as a fallthru in case no onclick function exists on the cell. if the args exist on the cell, it uses them, otherwise it uses the args from the cell header (altho this maybe should be the value from the cell).
Good. This is what I had in mind.
Now users can register a handler for any event they actually want to support, instead of the library trying to guess.
The only problem was trying to resize everything when it wasn't showing.
Having the extra space there is annoying when you dont have to scroll...
I'll take a look. I liked the disabled look when you didnt have to scroll, but I can see people might like it to go away.
This means that you can register any event you like, but you do not have to define them per cell/row. You define them once per table (you can redefine them later as well) and handle the logic for cell/row yourself within the event handler.
0
Right... well... because of the way sorting works ( it doesn't actually sort your table, it makes a sort-reference table ) You must call it when the data changes... I think refresh used to work back before I made sorting... it's been a while. I know you don't sort... but if you add data to the table I don't think you'll get the needed references in the sort table... that might be something I could fix... I'll have to think about that one. In the mean time, just call SortData after each addition ( or group of additions, if possible )
0
I fixed the link. I did have a page for DoCellUpdate. There's not a TON of information about it yet, but I did have a page, the link was just broken :)
0
The good news is providing a custom DoCellUpdate function isn't too bad, and lets you position textures perfectly. See this link. On the right hand side with the gear icons is a lib-st table. The icon cells also have a hover-over for displaying a tooltip.
Here is an example from the dkp mod where I use it.
0
you shouldnt need to setdata with the same table. just appending the data to your data table backend... resorting or calling refresh should do the rest.
Where will the garbage churn be around? I've put in some fixes for unneeded table creation, can you point out any other places?
0
I've also been worried that the structure of lib-st does not follow any of the AceGUI conventions... and a rewrite would be hefty. I hope you find the lib useful and easy to work with.
0
0
0
0
0
0
0
You'd have to reset the column information and data information.... It might not be worth it. Try it out though and let me know if you run into problems.
0
Good. This is what I had in mind.
Now users can register a handler for any event they actually want to support, instead of the library trying to guess.
0
Having the extra space there is annoying when you dont have to scroll...
I'll take a look. I liked the disabled look when you didnt have to scroll, but I can see people might like it to go away.
0
http://www.wowace.com/projects/lib-st/tickets/7-rightclick-events-do-not-work/
This means that you can register any event you like, but you do not have to define them per cell/row. You define them once per table (you can redefine them later as well) and handle the logic for cell/row yourself within the event handler.