i dont see why not, its all in the hands of the developers. i mean it is kind of brain numbing that i can not use my keyboard as intended, maybe the developers are not aware how a european keyboard looks like?
for the . instead of the , which would be in place where it is intended for most european keyboard i have to travel somewhere else making typing numbers blindly and fast impossible.
why not allowing us to switch the two, and using . for coordinates for those who use that function, which i personally never do, and i am not sure if there are really so many who would miss that anwayā¦
soā¦ what is the problem? why is nobody listening? yeah i understand its a papercut which nobody actually needs because it does not concern people from the states. idk i am so infuriated by the reluctance.
which hopefully do not feel addressed. otherwise how should i refer to the developers responsible for this specific issue, or the one sole person responsible for putting it on an actual do to list?
maybe i misunderstand your concern here, but this specific black hole deep essential issue drives me nuts, making spaghetti out of my hands to get in the numbers just does not feel efficient and professional.
This thread dates from 2015 (9 years ago). If a decimal comma is not implemented in Rhino 9 WIP now, most likely we will have to wait until Rhino 10 or Rhino 11 before this happens. My son will be happy to use decimal comma in Rhino (I still donāt have a son). Sorry for the humour.
well half of our worldly population does not use points but commas,
meaning 50% of people using Rhino are neglected?
ā¦simply crazyā¦
i lost you there trying to interpret your humourā¦
thank you @wim i saw that you added an entry, but i am afraid its not going to happen, āfutureā translates to me to not being on an actual to do list but saved as a reference. who can make that happen? 50% of users (ok am not having actual Licence Numbers but it seems fair enough to calculate like this) seems like a heavy number not to consider.
Well, we did implement the option to use the comma as decimal separator in the dimension settings, and did implement the first angle projection in 4View and Make2D. Those were the result of very deliberate developer actions.
Iām not sure what, if anything, was implemented with RH-53541 - perhaps @dalelear can comment on that.
For coordinate entry, you will need both the comma and the period anyway. RH-64708 Numeric entry - accept commas for single numeric entry ā When inputting a single value, it makes a lot of sense to use the separator key that is part of the numeric pad on the keyboard, and Iām hopeful that we can get to that at some point.
-wim
In contexts where we are 100% certain we are parsing a number, we can enable comma as a decimal point and thatās whatās done in the situations Wim mentioned above. However, in parsing of a sequence of characters, we are often in situations of accepting points, numbers, or strings and do not have enough context specific information. This is explained in more detail in RH-53541.
The code that parses input can be configured to parse all possible UNICODE values that might be used as a decimal point. However, when parsing general string input we cannot treat a comma as a decimal point for reasons explained above.
The point made above about the NUMERIC KEYPAD DECIMAL point key is valid and worth considering. It has been more than a decade since Iāve worked on physical keyboard input hooks and I donāt know how we do that on all platforms.
The Windows KEYCODES for the 3 keys (period, command and numeric keypad decimal) are different.
Numeric keypad decimal point key is VK_DECIMAL = 0x6E = 110.
Keyboard comma key is VK_OEM_COMMA = 0xBC = 188
Keyboard period key is VK_OEM_PERIOD = 0xBE = 190
I donāt know how this is handled on Apple devices.
I might be possible to have Rhino use a keyboard hook to have the VK_DECIMAL generate a period character in all locales. However, this might break things Iām unaware of.
@stevebaer@mikko Is it reasonable to experiment with having the VK_DECIMAL key generate a period in all locales? Have we already tried this?
Since this topic was initially brought up under the Mac category, it seems like we would need to figure out what options are available on Mac.
Parsing commas could be done for single numbers being input. The tricky bit is when parsing 3d points as Rhino allows for entering one, two, or three numbers for a single 3d point. If we allowed for the character that separates numbers to be something other than a comma, we could figure out how to properly parse. When commas are used for both the decimal separator and for the number separator we canāt figure out if
1,2,3 means a point at x=1, y=2, z=3 or it means a point at x=1.2, y=3, z=0
would it be possible to have a Rhino option that allows to simply switch . with , and use the comma as a decimal separator and the dot as a coordinate separator? maybe i am missing something obvious, but would that not be the easiest way to implement it? since i never user coordinates my opinion might be a bit biased in saying that i certainly would not mind using dots for coordinates.
just to be sure since i may lack on some terminology here:
if i make a circle and enter 5,5 then i would expect it to become 5,5 cm in diameter or whatever is set.
when i enter 5,5 in the gumball distance that it results in moving 5,5 cm. when i make a line i expect it to be the same, ok here it may become tricky since i can probably use both coordinates and numbers, but then again if we simply could switch the two symbols optionally i mean of course inverting their address it might all go away?
you mean existing ones? for those who use specific macros that contain coordinates, decimals, there are many quick ways to rewrite them with a text editor with search and replace functions, a matter of a few seconds/macro.
Many things can be a matter of seconds, but then youāll find that macros are also part of scripts and even compiled plug-ins, and that macros, scripts and plug-ins are in the thousands out there, if not even more.
Making a change like that would also amount to ābreaking the SDKā, something we try not to do (yes, I am aware it happens accidentally).
And that is not even thinking about how to handle stuff written for one way, but being used in Rhino configured for the other.
Itād be far easier and less intrusive to catch the numpad period key press and use the correct character in Rhino instead - use . instead of passed in ,.
i got you Nathan, i can not answer how difficult that might be to change compiled plug ins, maybe its the same effort with find and replace? but i am not the expert, i am only the one who wants the keyboard to work so i am not the right person to debate with here.
i am not sure i understood how the keyboard event handling could be imrpoved here or what it even means, i had that idea that when you use coordinates to make it obligatory to use all three coordinates, so that it must contain 2 separators in succession without space which may me distinguishable from decimals.
My son will be happy to use decimal comma in Rhino (I still donāt have a son). 
Sorry for the humour.
