LibBars-1.0:
Let's try adjusting the update rate based on the max time of the bar and the
bar width, in pixels. Since the bar can't shrink/grow in increments greater
than one pixel, there's no point in updating more often than every maxVal /
width seconds.
While this is a good idea, it created a bit of an aesthetic issue on bars with long timers, maybe 5+ minutes, I'm unsure of the exact margin. Since 1 second may move the bar less than 1 pixel, the timer doesn't update until it does. This results in the time countdown skipping multiple seconds at a time and it looks like it's lagging.
I am receiving the following error with LibBars-1.0 r76735 ever since it was moved to the trunk.
[2008/06/16 09:55:36-243-x1]: LibBars-1.0\LibBars-1.0.lua:1112: attempt to call field '?' (a nil value)
LibBars-1.0\LibBars-1.0.lua:823: in function <...rface\AddOns\LibBars-1.0\LibBars-1.0\LibBars-1.0.lua:818>
[2008/06/17 16:39:49-245-x1]: LibBars-1.0\LibBars-1.0.lua:196: attempt to index field 'ownerGroup' (a nil value)
LibBars-1.0\LibBars-1.0.lua:1113: in function `func'
LibBars-1.0\LibBars-1.0.lua:824: in function <...rface\AddOns\LibBars-1.0\LibBars-1.0\LibBars-1.0.lua:819>
Hi, nice work on the lib. I couldnt find an "official" thread for it, so i thought i'd tag my problem onto this thread, hope you dont mind.
Symptom: The bar continues to "flash" after the time is completed.
How to reproduce:
1) Create 2 groups
2) Create a bar on group1
3) Move the bar to group2
4) Wait for Timer expiry
It seems the callback is being issued to the group the bar was originally created in, and not on its ownerGroup. Thus ReleaseBar is being called to the original groups instance, which cant find a bar with that name.
I fixed it by changing line 511 from:
lib.ReleaseBar(self, bar)
to
lib.ReleaseBar(bar.ownerGroup, bar)
(havent tested other implications of this fix yet, just wanted to get it working so i can continue development)
Just a note on above, it breaks the callback trigger, should have thought about that before.
EDIT: Actually, not strictly true, extra FadeFinished callbacks not fired because the bar is release before it gets around to triggering them (the libs FF callback is called first, releasing the bar and unsetting the callbacks). So my first post still stands (until i find something else to prove it wrong!), but this FadeFinished callback deletion is a bit of a problem for me at the moment. gonna look into it a bit more later tonight.
ok, i managed to get a bit of time to tweak things.
As well as the change listed in my first post, i also commented out the callback cancelling. The reason being as an addon author i need all my callbacks to be triggered regardless of the bars state of existance. i feel its the addon authors responsibility to check if the bar still exists when their callback is fired.
My scenario was that when a bar was completed, i need to run a cleanup routine. I needed to run it after the fade, (not at the TimerFinished) otherwise my cleanup would just destroy the bar before it faded. Aesthetic, yes.
Commenting out the callback removal allowed my cleanup code to be fired. I dont know how this affects recycling of bars.
I've attached a patch file.
While this is a good idea, it created a bit of an aesthetic issue on bars with long timers, maybe 5+ minutes, I'm unsure of the exact margin. Since 1 second may move the bar less than 1 pixel, the timer doesn't update until it does. This results in the time countdown skipping multiple seconds at a time and it looks like it's lagging.
Or possibly update the countdown only once a second and only update the other stuff based on the current update
[2008/06/16 09:55:36-243-x1]: LibBars-1.0\LibBars-1.0.lua:1112: attempt to call field '?' (a nil value)
LibBars-1.0\LibBars-1.0.lua:823: in function <...rface\AddOns\LibBars-1.0\LibBars-1.0\LibBars-1.0.lua:818>
---
I can revert to r74228 and this issue goes away.
[2008/06/17 16:39:49-245-x1]: LibBars-1.0\LibBars-1.0.lua:196: attempt to index field 'ownerGroup' (a nil value)
LibBars-1.0\LibBars-1.0.lua:1113: in function `func'
LibBars-1.0\LibBars-1.0.lua:824: in function <...rface\AddOns\LibBars-1.0\LibBars-1.0\LibBars-1.0.lua:819>
---
6/24 20:39:59.109 Global variable classFileName tainted by LibBars-1.0 - Interface\FrameXML\FriendsFrame.lua:582
6/24 20:39:59.109 GuildStatus_Update()
6/24 20:39:59.109 Interface\FrameXML\FriendsFrame.lua:780 FriendsFrame_OnEvent()
6/24 20:39:59.109 FriendsFrame:OnEvent()
6/24 20:39:59.109 Execution tainted by LibBars-1.0 while reading classFileName - Interface\FrameXML\FriendsFrame.lua:599
6/24 20:39:59.109 GuildStatus_Update()
6/24 20:39:59.109 Interface\FrameXML\FriendsFrame.lua:139 FriendsFrame_Update()
6/24 20:39:59.109 Interface\FrameXML\FriendsFrame.lua:781 FriendsFrame_OnEvent()
6/24 20:39:59.109 FriendsFrame:OnEvent()
6/24 20:39:59.109 An action was blocked in combat because of taint from LibBars-1.0 - RaidFrame:Hide()
6/24 20:39:59.109 Interface\FrameXML\FriendsFrame.lua:35
6/24 20:39:59.109 FriendsFrame_ShowSubFrame()
6/24 20:39:59.109 Interface\FrameXML\FriendsFrame.lua:140 FriendsFrame_Update()
6/24 20:39:59.109 Interface\FrameXML\FriendsFrame.lua:781 FriendsFrame_OnEvent()
6/24 20:39:59.109 FriendsFrame:OnEvent()
t
Symptom: The bar continues to "flash" after the time is completed.
How to reproduce:
1) Create 2 groups
2) Create a bar on group1
3) Move the bar to group2
4) Wait for Timer expiry
It seems the callback is being issued to the group the bar was originally created in, and not on its ownerGroup. Thus ReleaseBar is being called to the original groups instance, which cant find a bar with that name.
I fixed it by changing line 511 from:
to
(havent tested other implications of this fix yet, just wanted to get it working so i can continue development)
Hope this helps,
Oridan
EDIT: Actually, not strictly true, extra FadeFinished callbacks not fired because the bar is release before it gets around to triggering them (the libs FF callback is called first, releasing the bar and unsetting the callbacks). So my first post still stands (until i find something else to prove it wrong!), but this FadeFinished callback deletion is a bit of a problem for me at the moment. gonna look into it a bit more later tonight.
Cheers
As well as the change listed in my first post, i also commented out the callback cancelling. The reason being as an addon author i need all my callbacks to be triggered regardless of the bars state of existance. i feel its the addon authors responsibility to check if the bar still exists when their callback is fired.
My scenario was that when a bar was completed, i need to run a cleanup routine. I needed to run it after the fade, (not at the TimerFinished) otherwise my cleanup would just destroy the bar before it faded. Aesthetic, yes.
Commenting out the callback removal allowed my cleanup code to be fired. I dont know how this affects recycling of bars.
I've attached a patch file.
Hopefully my ramblings make sense!