by Michael S. Kaplan, published on 2013/09/07 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2013/09/07/10435263.aspx
The other day, friend and colleague Dave asked:
Hi all,
I’m working with a customer who wants his .NET Winforms app to always display the western Arabicnumerals (“1234567890”), for the Unicode characters 0x30-0x39.
This is the normal behavior of course, but, in Control Panel, you can tell the system to display“native” digits instead…
So, if your User Locale were,say, “Arabic (Saudi Arabia)”, then the Unicode string “123”would get displayed as “١٢٣”. The customer wants to avoid this in hisapplication and display exactly what his string contains (“123”).
Now, the DigitSubstitution property appeared to be exactly what he wanted, since it allows him to set a value of None, which per the documentation, makes the digit always follow the Unicode string (i.e. it does not change the shape of the digit).
Unfortunately, this property has no effect. Reading further, the docs state…
The DigitSubstitution property is reserved for future use. Currently, it is not used in either parsing or formatting operations for the current NumberFormatInfo object.
So, I tried explicitly changing the above Control Panel setting *to 1* with SetLocaleInfo (…LOCALE_IDIGITSUBSTITUTION). This works of course, but now the question is – is there any less-invasive way to accomplish this? By less-invasive, I mean, any way to do this without affecting other apps with a system change?
Thanks for any suggestions!
David
Good question!
Unfortunately, there isn't really a very good answer. 😒:-(
There is no way to do it without changing the digit substitution properly for the entire system or work with low level GDI functions.
Or do what you're doing now.
Sorry! 😞:-(
John Cowan on 7 Sep 2013 2:11 PM:
OT for this post but not this blog:
I have just released the open-source U.S. Moby Latin keyboard (made with MSKLC, of course!) It supports more than 650 characters while remaining compatible with the standard U.S. keyboard. There are no less than 21 deadkeys, but they are all in the AltGr shift state, so people's regular typing habits can remain intact.
(Michael, it turns out that when you have two deadkey tables with the same deadkey, even if they are exactly identical, MSKLC builds a keyboard that only semi-works instead of failing at build time. I eventually went in with WordPad and removed one of them from the source.)
So far I have only tested it on 64-bit Windows 7. Interested readers can fetch it from www.ccil.org/.../MobyLatinKeyboard.zip.
cheong00 on 9 Sep 2013 3:53 AM:
Maybe a WPF RichEditBox hosted in the WinForm will do.
social.msdn.microsoft.com/.../how-to-make-contentcontrol-to-reload-the-content-digit-substitution
Doug Ewell on 10 Sep 2013 9:32 AM:
Gotta try John's keyboard. This has been on my list for a long time.
Alex Cohn on 10 Sep 2013 8:24 PM:
I wonder, is there a reliable way to display hexadecimal numbers? 0x1B will look terrible if Native substitution is enforced.
Alex Cohn on 10 Sep 2013 8:30 PM:
Actually, I guess I have an answer to my question as well as to David's original one: use the U+FF1x instead of U+003x
Alex Cohn on 12 Sep 2013 1:00 PM:
BTW, the question happens to be 3 years old: stackoverflow.com/.../disable-digit-substitution