search

buixuanan / fritzing

Automatically exported from code.google.com/p/fritzing
0 stars 0 forks source link

lost a decimal in grid option #2975

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. open new fritzing build
2. try to modify the grid size to an 0.1inch factor
3. it's just possible to write a 3digits long number (e.g. 0.10inch, 0.05inch) 
but not a number with 4 or more digits like 0.025inch. in fritzing 0.8.xb it 
was possible. 

from my point of view it's really important to make this option available 
again. sometimes i have to use a gridsize of 0.0125 inch. 

test: win7 64bit in 32 and 64bit qt5.3.1 build.

Original issue reported on code.google.com by bluearc....@gmail.com on 8 Jul 2014 at 11:16

Attachments:

GoogleCodeExporter commented 9 years ago 
besides, writing an  " , "  instead of a " . " makes the grid really huge and 
can 
produce a strange behavior. (especially during fab runs) maybe we can 
define both characters to the same meaning. in the drc-window you cannot even 
type a dot for the "drc-range"

Original comment by bluearc....@gmail.com on 8 Jul 2014 at 12:55

GoogleCodeExporter commented 9 years ago 
seems to be an qt5.3.1 bug. the release version with qt5.2.1 has an other grid 
option bug. it's possible write more digits in the grid-size-field but you can 
just type "0" and one other number. so it's possible to make a 0.005 grid but 
not a 0.0025 grid.
not sure if this issue comes up on other platforms.

Original comment by bluearc....@gmail.com on 9 Jul 2014 at 12:38

GoogleCodeExporter commented 9 years ago 
the bug affects the german translation of fritzing.
english version don't have the bug. i assume it's a conversion problem from the 
german standard notation with a "," to the englisch notation with a "."
we have to test if it's on other platforms too

Original comment by bluearc....@gmail.com on 12 Jul 2014 at 4:20

GoogleCodeExporter commented 9 years ago 
Fixed in revision dbc1f6e225a9 by enforcing the "." separator for all locales. 
Also for other occasions of the same bug.
Using the correct local separator depending on the selected language would be 
nicer, but this would require much more work, because several functions simply 
assume a "." when converting numbers from strings.

Original comment by andre.knoerig@gmail.com on 12 Jul 2014 at 7:53