sure, but for me to really understand super minimal repros are helpful... there is not "ready" anything here: http://haxeui.org/builder/?d32b80ef, so if i have to invent it, its possible (probable?) ill get the repro wrong and it will all be fine.

sorry - incomplete message on that front

ok So the min and max labels are set to the slider min and max divided by the scale and rendered with a post-decimal point precision number of places

this is working for the min but not the max

but a few minutes ago it was right for both

but of course I've changed code 🙂

sure, but yeah, trying to work backwards from words is almost impossible for me, if you could code me up a minimal repro then a) ill instantly understand and b) we have a test case to apply to DoD

I don't know about minimal but it's

if you have to go - go - I'll figure it out eventually

looks pretty minimal to me

but the code in question is how lsMax.text is being set in the cbk

you mean that its saying "7000" rather than "70.0"?

i presume it must be a logic bug in "formatFloat", because if i change it to "lsMax.text = Std.string(lsSlider.max);" it just shows "70"

ah .... I missed a case

it is in there

the problem is that because 70.0 is 4 chars, and my precision is 4 the code breaks

alright, im really going to bed now ( 🙂 )... haxeui issue or user code issue?

im thinking the latter as without formatFloat it all seems fine

oh no - not haxeui - mine

sorry - to waste your time

cool... ill sleep better having not added some weird "on ready" bug to my list 🙂

no hassle, no bother... sleep well! 🙂

thanx

So I have this going with a custom component. http://haxeui.org/builder/?afea4275 This solves 2 problems. It scales the slider so that it can provide a slider for values less than one, and it provides a single component with labelling and string formatting that supports a range < 1.0. But then I went back and looked at https://github.com/haxeui/haxeui-core/blob/master/haxe/ui/components/Slider.hx. It seems it has a notion of precision and step that should have been able to do the slider for values of less than one thing. But it appears it cannot. I added a similarly set up slider and labels to the test case and indeed it doesn't slide neatly - just goes to either end. So am I right in assuming that sliders really need to be over ranges numerically greater than 1.0 or have I missed something ?

I think it's a bug 🙂 . It should work.

It has to do with haxe.ui.util.MathUtil.roundToNearest(0.094, 0.01) is 0

haxe
 public static inline function roundToNearest(v:Float, n:Float):Float {
        var r = v % n;
        if (r <= n / 2) {
            return Math.fround(v - r);
        }
        return Math.fround(v + n - r);
    }

It used Math.fround which rounds to the nearest integer

yeah, defo looks like a bug in slider / mathutil

ah ok - makes sense - I saw the start and end behaviours but I don't understand how they work and I thought they only covered hitting the end stops rather than other spots on the slider - but then I couldn't see where the rest of the slider was covered - so yeah time to plead for help 🙂

I know this is probably not a priority, but I am testing a few things with the AIR target using

lime test air -debug

, and am getting a compilation error from haxeui-core.

C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/util/ImageLoader.hx:132: characters 41-56 : haxe.Http has no field responseHeaders
C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/util/ImageLoader.hx:134: characters 41-56 : haxe.Http has no field responseHeaders

I don't have a small sample app, but I assume it is probably easy to repeat, although getting the AIR SDK can be a pain.