Problem with negative values in InputField

[DevJohan]

I don't know if extending the parser to include more unicode characters is the the right way to go. This increases the complexity of the parser without much gain. What I propose is to complement InputField::fixup(...) and QuantitySpinBox::fixup(...) to read something like

Code: Select all

void CLASS_NAME::fixup(QString& input) const
{
    input.remove(locale().groupSeparator());
    if(locale().negativeSign() != QChar::fromAscii('-'))
    	input.replace(locale().negativeSign(), QChar::fromAscii('-'));
    if(locale().positiveSign() != QChar::fromAscii('+'))
    	input.replace(locale().positiveSign(), QChar::fromAscii('+'));
}

and call this function before sending the code to the parser. Another similar replacement would be the decimal point character which at the moment both '.' and ',' is accepted by the parser. From what I've read german locale uses '.' for group separation and ',' as the decimal point. For me the most intuitive would be to either make the parser locale aware or removing locale specific constructs prior to parsing.

[jriegel]

Its no problem, since the Lex/Yacc style parsers are always seperated in scanner and parser. I can make the scanner read any kind of UTF8 sequence as minus token.

I think I will tackle also the number group thing in the parser. That will allow any kind of number grouping working....
* 1.3434.334,44234mm
* 1,2323,234.345345in

It will be a tricky regex, but should be be doable....

I will not allow
* 123,232in as grouping
you have to write at least:
* 123,232.0in

[wmayer]

And what about ?
* 1,3434,334.44234mm
* 1.2323.234,345345in
i.e. German group separator combined with imperial units. The point is group and decimal separator are system settings while the unit system is a user setting.

[jriegel]

Since the number and unit interpretation are separate, both will work.

My aim is to keep the unit parser locale agnostic since it is in the base system. If FreeCAD runs headless or by scripts, no locale is set...

[jriegel]

I can use the minus, but the other group seperators are to strange.

I will only support dot and comma....

[wmayer]

I think that's fine.

[jriegel]

Ok I added the special minus. Please test someone with Swedish keyboard

I did not get the locale agnostic groups managed. So I would fall back to the DevJohans solution and replace critical chars in front of the parser.

@DevJohan
You have a working branch? Then I can pull and test....

[obbe]

I tried to download and compile it, but the dependencies are huge, so I don't have the space on my hard drive.

But isn't it enough with pasting the offending character (− I believe)? Without being an expert, the fix seemed global.

[ralvejd]

Ok I added the special minus. Please test someone with Swedish keyboard

The Swede has tested, the minus sign works fine now.
I even tried to use the . or , for decimal numbers, they worked both.
The . was nicely replaced with a , automatically.
The test is carried out with the Placement dialogue in Part Design.

On behalf of all 9 million Swedes , I thank you!

OS: Debian GNU/Linux 7.6 (wheezy)
Word size: 64-bit
Version: 0.15.3829 (Git)
Branch: master
Hash: 234af5b27f997ee3e5dfa86e76ffe5521b31d532
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 3.1.3
SoQt version: 1.5.0
OCC version: 6.7.0

[jriegel]

On behalf of all 9 million Swedes , I thank you!

Your welcome!