Crash on sliders sliding into the negative
Closed this issue · 18 comments
Found in commit 297e44d
Related to #47 #48
Every time a slider has a negative value the following exception happens.
(Widgets > Basics)
Exception in thread "hmd-renderer" java.text.ParseException: Unparseable number: "-2%"
at java.base/java.text.NumberFormat.parse(NumberFormat.java:393)
at imgui.imgui.imgui_internal$Companion.roundScalarWithFormat(internal.kt:3498)
at imgui.imgui.imgui_main$Companion.dragBehaviorT(main.kt:658)
at imgui.imgui.imgui_internal$DefaultImpls.dragBehavior(internal.kt:1552)
at imgui.ImGui.dragBehavior(imgui.kt:45)
at imgui.imgui.imgui_widgetsDrag$DefaultImpls.dragScalar(widgets drags.kt:266)
at imgui.ImGui.dragScalar(imgui.kt:45)
at imgui.imgui.imgui_widgetsDrag$DefaultImpls.dragScalar$default(widgets drags.kt:212)
at imgui.imgui.imgui_widgetsDrag$DefaultImpls.dragInt(widgets drags.kt:133)
at imgui.ImGui.dragInt(imgui.kt:45)
at imgui.imgui.demo.widgets.invoke(widgets.kt:378)
at imgui.imgui.demo.ExampleApp.invoke(ExampleApp.kt:180)
at imgui.imgui.imgui_demoDebugInformations$DefaultImpls.showDemoWindow(demo debug informations.kt:91)
at imgui.ImGui.showDemoWindow(imgui.kt:45)
at imgui.imgui.imgui_demoDebugInformations$DefaultImpls.showDemoWindow(demo debug informations.kt:87)
at imgui.ImGui.showDemoWindow(imgui.kt:45)
at com.chrjen.pluto.gui.VRScene$VRRenderer.loop(VRScene.java:748)
at com.chrjen.pluto.gui.VRScene$VRRenderer.lambda$run$0(VRScene.java:270)
at uno.glfw.GlfwWindow.loop(GlfwWindow.kt:503)
at com.chrjen.pluto.gui.VRScene$VRRenderer.run(VRScene.java:269)
at java.base/java.lang.Thread.run(Thread.java:844)
This happens for every slider I tried that allows me to slide the value into the negative.
DEMO EXCEPTION: Unparseable number: "-0.0004"
DEMO EXCEPTION: Unparseable number: "-59 deg"
DEMO EXCEPTION: Unparseable number: "-0.008700 ns"
DEMO EXCEPTION: Unparseable number: "-425 units"
DEMO EXCEPTION: Unparseable number: "-60"
This seems related, might want to read it. I tried running this code here.
NumberFormat.getInstance(Locale.GERMANY).parse("-5");
NumberFormat.getInstance(Locale.CHINESE).parse("-5");
NumberFormat.getInstance(new Locale("en", "GB")).parse("-5");
NumberFormat.getInstance(new Locale("no", "NO")).parse("-5");
Crashed on the fourth line Unparseable number: "-5". (It's the default local set by my computer)
Also it got closed as "Not an Issue" so it's apparently not a bug and is intended behaviour.
Yeah I just tried running my program on a JVM using a different default local and it doesn't crash anymore. So it only crashes depending on what region of the world you are from, lol.
If you can't reproduce the bug, try running the JVM with the arguments -Duser.country=NO -Duser.language=no. I'm also using Java 9 which might be relevant.
-Duser.country=NO -Duser.language=no did actually help to reproduce the error, coz I was having no excepetion with negative ns float dragging field.
Uhm, that's tricky to resolve. Shall we maybe detect and react according to the current locale?
Any tips?
Which was your original locale that provoked the crash?
My original locale is Norwegian no_NO.
I can really give any tips though as I have no idea what roundScalarWithFormat does or why the parse is necessary. Rounding by converting to string, then back again seems really strange to me (at least that's what I think it is doing).
In a comment, Omar wrote Round to user desired precision based on format string
I'll think about it
In the meanwhile... why the hell does it crash with negative values using Norwegian locale...? lol
Anyway, I just pushed a workaround, DecimalFormat will always use as locale style.locale (which is now a var and default US)
Don't think I understand Omar's thinking then. I don't see why the way a number is represented has to be tightly coupled with the actual value. If I wanted a slider with steps of 0.001 yet is formatted to only display a single decimal place of precision it should be my choice.
Anyway I got around to trying out the most recent commit (3620dfd) with the workaround and guess what, still broken, lol. The RGB sliders under (Widgets > Basics) causes the same exception to happen when the number of digits go below three due to the extra padding in front, Unparseable number: " 67", Unparseable number: " 4".
Would be nice to have locale not tied to US only. If the UI is in another language for example it would be nice having e.g. commas instead of a dot as a decimal separator if you set the locale that way.
I have no idea neither, but I'd guess he has his reasons, I need to check if this makes sense on jvm as well
Anyway, lol, man, what's wrong with norwegian format.. 😁
Pull again, dear. This time I also trim the begin of the string
As I said, default it us, but you can change it. It's style::locale
Ah, thank you. Though of course currently changing locale breaks the library..
I don't know why Norwegian is suppose to use a different minus sign. Also I just noticed I didn't seem to actually post the link in my previous comment that I intended for you to read -_-. Anyway this is what I found, link. In the reply it also links to a page on unicode that list which locales have different minus signs. So Norwegian is there (nb/nn) though it's not the only one using that special minus sign, but also Finnish, Swedish, Italian, etc.
Though of course currently changing local breaks the library..
What do you mean?
Uh, that link revealed to be actually quite important (I myself am italian...)
So, if we solve all the troubles you are having, I guess there is also a good chance we'll solve them also for all the other locales..
What do you mean?
Sorry, locale*.
Change the locale in imgui.style to e.g. Norwegian causes the same issues again. I mean your fix was to set the locale to US so naturally setting it to e.g. Norwegian again will make the unparseable number exception happen again.
I dont get any more exceptions..
I'm parsing now strings with DecimalFormat, it looks working flawless also for Norwegian locale
Give it a try
Tried commit fd68422 and it still throws the same ParseException as usual.
Just looking at the commit though I see nothing that has really changed except the default locale for everyone is now Norwegian instead of US.
Shit, that was unwanted :p
Anyway, I dont get why I dont get anymore the exception..
I tried passing -Duser.country=NO -Duser.language=no to JVM args..
However, I can still reproduce with
val dec = DecimalFormat().apply {
decimalFormatSymbols = DecimalFormatSymbols(Locale("no", "NO"))
}
dec.parse("-5")
So, let's face the problem from another point of view, let's substitute the old minus with the new out
Give me good news, man ^^
Sure thing! Good news it now works if you set imgui locale to Norwegian!
Bad news? Every other locale now breaks with the same exception due to the new minus sign, including the default US locale.
Ok, then let's switch it only given on the style.locale
Anyway, I'm going crazy.
You can easily do it and test on your machine, since you can reproduce it easily.
Do you mind working on it directly? :)
Ps: tried to send you an invite, but apparently there is no result for @chrjen
You’ll only be able to find a GitHub user by their email address if they’ve chosen to list it publicly. Otherwise, use their username instead.
Well I can always try to help. Don't know why the username doesn't work. Also don't really know Kotlin, but a solution in Java shouldn't be very hard to translate into Kontlin, right?
If needed, chrjen could join lwjgl slack and message you there
Also, as he prefers
Well I can always try to help. Don't know why the username doesn't work.
Try to send me your email, here or on elect86 gmail
Also don't really know Kotlin, but a solution in Java shouldn't be very hard to translate into Kontlin, right?
Right and then you'll love it and you are gonna switch everything to Kotlin :)