SciCalc decimal separator

The last version of SciCalc made a couple of changes to accommodate Territories with different decimal separators (e.g., a comma). This seems to work fine, as far as I can tell from the feedback.

One issue that remains is that the dot key on the numeric keypad still ought to input a decimal separator even when the actual character has been altered. The fix for this appears simple: altering line 337 of !RunImage from

WHEN ASC(DecimalPoint$):

to

WHEN &2E, ASC(DecimalPoint$):

Any problems with adding this?

The fix for this appears simple: altering line 337 of !RunImage

I’m not convinced that’s a good idea, no.

First of all, when comma is the decimal separator the dot ought to be the grouping separator and hence ignored. Secondly it means that even when the territory does not treat dot as a decimal, SciCalc does.

One issue that remains is that the dot key on the numeric keypad still ought to input a decimal separator even when the actual character has been altered.

A fascinating point which I’d never considered before. However, that’s a keyboard driver issue, not an application issue. If what you say is true (and I’m sure you’re probably right) then the user would want that to work everywhere, not just in SciCalc – BASIC, the command line (eg *CALC), spreadsheets.

So no, don’t do that. Fix the keyboard driver.

So no, don’t do that. Fix the keyboard driver.

Or not? The French use a comma as the separator yet the numeric keypad has a ‘.’. I don’t know if stuff like Excel is too braindead to accept a comma or if it accepts both?
At any rate, you want to consider carefully before making the keyboard output something different to what it says on the key cap.

So no, don’t do that. Fix the keyboard driver.

At any rate, you want to consider carefully before making the keyboard output something different to what it says on the key cap.

Yes, good points. Perhaps best to leave alone.

So no, don’t do that. Fix the keyboard driver.

Perhaps best to leave alone.

You’ve reminded me I did briefly research this a few weeks back and what I saw is mostly user frustration that some applications (complaints were often at MS Office) have their own local settings that you have to rummage around to set up, others interpret system wide settings in various differing ways, and generally it’s all a bit inconsistent.

I’d not be a fan of a keyboard driver that outputs a comma when clearly the keyboard I’ve bought has a dot on it, so “fix the driver” sounds wrong too – the driver isn’t broken, it probably can’t distinguish (certainly for PS/2, probably for USB) what the keycap says on it.

A quick search suggests that keyboards with different key tops for dot on the numeric keypad may be a bit hens-teeth-rare.

So this is probably something that should be remapped somewhere, at user discretion, maybe as a configure keyword for the territory, but not mangled by code changes in every individual app.

I’d not be a fan of a keyboard driver that outputs a comma when clearly the keyboard I’ve bought has a dot on it

I’m surprised your posts aren’t entirely in upper case then.

“fix the driver” sounds wrong too – the driver isn’t broken

Would you prefer “Add value to the user experience by adding functionality to the keyboard handler such that the user can choose whether the numeric keypad decimal separator honours the Territory or keyboard convention, in much the same way that the same user can choose whether the Backspace key deletes to the left or the right”?

“Fix the driver” was shorter.

So this is probably something that should be remapped somewhere

Indeed. Same place as the “PC delete” is – the keyboard handler (of which I have written many).

Would you prefer “Add value to the user experience by adding functionality to the keyboard handler such that the user can choose whether the numeric keypad decimal separator honours the Territory or keyboard convention.

Just to clarify – and just tried on mom’s French PC running Windows XP – the decimal dot of the numeric part of an AZERTY layout keyboard generates…..a decimal dot and not a comma. Despite the French using comma as the decimal separator.

Perhaps the “fix” is to let SciCalc accept either . or , and leave the keyboard alone.

Another test: My PC, XP with UK International keyboard driver, Windows Calculator. If I enter 123,45 then what appears in the calculator is 123.45.

It is clear that there are plenty of people in the wider world dissatisfied with the dot or comma on their keypad and the dot or comma on their screen.

just tried on mom’s French PC running Windows XP – the decimal dot of the numeric part of an AZERTY layout keyboard generates…..a decimal dot and not a comma. Despite the French using comma as the decimal separator.

Meanwhile, someone else, somewhere else writes:

I work in Germany and have a european keyboard/settings, so instead of a dot between the 0 and Enter key on the number-keypad, I am stuck with a comma.

Having a keyboard handler option would therefore appear to be a no-brainer.

*Configure KeypadDot Dot

*Configure KeypadDot Comma

*Configure KeypadDot Auto

Perhaps the “fix” is to let SciCalc accept either . or , and leave the keyboard alone.

Well it certainly must when the Territory mandates a comma, but I agree that people don’t generally want to type in thousands separators too.

However, good luck getting BASIC to support commas in code – PRINT 1,2.3,4.5,6. Supporting commas in input is another matter entirely of course.