I'm Aceifying some of my addons and this is my first go (in years, I guess) with using Ace so I prettymuch have to re-learn it all.
I'm SetPoint'ing my default unitframes based on a db value set using AceConfig(GUI) and I'm getting some weird behaviour. the Y slider has the range -500 to 500 and when I move the slider up from -500 to 500 it stops at 50% and snaps back to -500.
at line 157 I have a print that prints the value that the setter is getting and that's just -500 on my screen if I move the slider over 50%. I can still use the value input of the slider to set the value above 0.
After some struggling I found that I need to define step=1 in the options in order for it to work normally.
Isn't this supposed to be defaulting to 1 already?
AceGUIWidget-Slider.lua line 181-183:
frame:SetMinMaxValues(min or 0,max or 100)
UpdateLabels(self)
frame:SetValueStep(step or 1)
This might be a bug with the widget then..
why should it default to 1? maybe i have a slider going from 0 to 1 and want everything in between seams to be more a code problem on your end rather than the sliders
if it would default to a value then you would have a very hard time getting max precision between numbers as such leaving it off and allowing you to set your own step is the best solution atm.
as for it not working correctly i don't know i have never had a problem with it (with step and without)
It makes sense not to have defaults of arbritrary value, there can't be a one size fits all default. Just set it. For the record, here's the documentation:
If no "min" or "max" are specified, the manual input of the range control will accept any and all values!
...
step - step value: "smaller than this will break the code" (default=no stepping limit)
Note that you can consider the fact that the author used defaults as an error checking condition to prevent crazy errors showing in the addon. Just because defaults were supplied that doesn't mean they shouldn't be entered.
I wouldn't personally agree that this is a bug. An alternative would have been for the lib author to throw an error if they weren't set. Which I suppose would have helped your cause as you'd have known sooner that the values should be specified.
I'm Aceifying some of my addons and this is my first go (in years, I guess) with using Ace so I prettymuch have to re-learn it all.
I'm SetPoint'ing my default unitframes based on a db value set using AceConfig(GUI) and I'm getting some weird behaviour. the Y slider has the range -500 to 500 and when I move the slider up from -500 to 500 it stops at 50% and snaps back to -500.
code: https://gist.github.com/2c31902dfb865e130a3b/ee2aa0444d548690e94e033e80ce335ecdd4e3f7
at line 157 I have a print that prints the value that the setter is getting and that's just -500 on my screen if I move the slider over 50%. I can still use the value input of the slider to set the value above 0.
Edit: Current tree is at https://github.com/Industrial/idAddon/tree/01aa0701a5dd840993a2f8b4d824a29380cc9796
Isn't this supposed to be defaulting to 1 already?
AceGUIWidget-Slider.lua line 181-183:
This might be a bug with the widget then..
why should it default to 1? maybe i have a slider going from 0 to 1 and want everything in between seams to be more a code problem on your end rather than the sliders
What should it default to then?
If it doesn't default to a value and it seemingly doesn't work correctly without it being specified then that's a bug, no?
If it shouldn't default to a value then it should be a mandatory option, imho.
as for it not working correctly i don't know i have never had a problem with it (with step and without)
http://www.wowace.com/addons/ace3/pages/ace-config-3-0-options-tables/
And here's the relevant quote:
Note that you can consider the fact that the author used defaults as an error checking condition to prevent crazy errors showing in the addon. Just because defaults were supplied that doesn't mean they shouldn't be entered.
I wouldn't personally agree that this is a bug. An alternative would have been for the lib author to throw an error if they weren't set. Which I suppose would have helped your cause as you'd have known sooner that the values should be specified.