+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: [LDCad] Thousands separator/decimal point confusion (/thread-24875.html)
Thousands separator/decimal point confusion - Owen Dive - 2021-08-15
Greetings.
I've just stumbled across what I think is a small bug in LDCad. Since there's a 1.7 version in the works, now's as good a time as any to have found it!
For parts that are far away from the origin (more than 1000LDU), if I open the Reference/selection properties box to put in new coordinates, the numbers/s are displayed with commas as thousands separators. But when I hit Accept to dismiss that box, that comma gets interpreted as a decimal point, and my part moves much closer to the origin - from x=1020 (say) to x=1.02.
Have I described that well enough? Feel free to ask any clarifying questions.
I'm using LDCad 1.6d (LNX64). I don't think I've done anything special with my system localisation settings.
Apologies if this is a known bug, I couldn't find anything on the website or the release notes.
Thanks again for a great product.
Owen.
RE: Thousands separator/decimal point confusion - Roland Melkert - 2021-08-15
(2021-08-15, 5:00)Owen Dive Wrote: if I open the Reference/selection properties box to put in new coordinates, the numbers/s are displayed with commas as thousands separators. But when I hit Accept to dismiss that box, that comma gets interpreted as a decimal point, and my part moves much closer to the origin - from x=1020 (say) to x=1.02.Strange, i can't replicate this in mint. Which flavour os, and country settings are you using?
I think it is external though, as LDCad doesn't actually use locale information. It accepts both dot and comma anywhere.
It does use the preferred separator when presenting numbers, but never includes thousand separators.
Is it possible the gui frontend adds that 'automagically' ?
RE: Thousands separator/decimal point confusion - Owen Dive - 2021-08-15
(2021-08-15, 6:55)Roland Melkert Wrote: Strange, i can't replicate this in mint. Which flavour os, and country settings are you using?
I think it is external though, as LDCad doesn't actually use locale information. It accepts both dot and comma anywhere.
It does use the preferred separator when presenting numbers, but never includes thousand separators.
Is it possible the gui frontend adds that 'automagically' ?
Hmm.
I'm also using Mint (19.1 Tessa), with Australia in all the places I could think to specify.
Quite possible that this is external to LDCad. A bit rude of the OS to insert the comma into the number though - how does it know that the string of digits represents an integer and not, say, a serial number??
Maybe I'll just leave it for a while and it'll fix itself. That's what happened last time I was having problems with LDCad dialog boxes!
RE: Thousands separator/decimal point confusion - Roland Melkert - 2021-08-15
(2021-08-15, 8:14)Owen Dive Wrote: Quite possible that this is external to LDCad. A bit rude of the OS to insert the comma into the number though - how does it know that the string of digits represents an integer and not, say, a serial number??
I checked the source, it is using the system default for formatting numbers when prepping for display.
I thought this only affected the decimal separator, but apparently this (sometimes) includes the thousand separators.
Thanks for reporting, I'll force Alpha 2 to leave the thousand separators out.
RE: Thousands separator/decimal point confusion - Roland Melkert - 2021-08-15
(2021-08-15, 16:21)Roland Melkert Wrote: I checked the source, it is using the system default for formatting numbers when prepping for display.
I thought this only affected the decimal separator, but apparently this (sometimes) includes the thousand separators.
Thanks for reporting, I'll force Alpha 2 to leave the thousand separators out.
It turns out I was confusing the 2.0 code (as I worked on that last), which has a fully custom dblToStr implementation where 1.X uses std streams.
Maybe I should replace all number conversions with the 2.0 code, adding scientific notation support as a bonus.