Our system use Access VBA function Chr() to get ASCII code to generate barcode. All of computers (include Windows 10, Windows 8 and Windows 7) result of Chr() is correct while one of Windows 8.1 result is different.
For example
All computers return of Chr(209) is “Ñ” which is correct. Return of Ch(65) is “A” which is correct.
One computer return of Chr(209) is “?” which is incorrect. Return of Ch(65) is “A” which is correct.
I try to use ChrW and ChrB. Both still do not return proper ASCII. Not sure why that computer return is different. Test results from computers and seems that computer cannot return correct ASCII for 128~256 codes.
ASCII codes were supposed to be a defined standard but that standard keeps changing. Depending on your region or your software versions you could have a mismatch in what you would expect to be returned. This is why you will see items like <?xml version=“1.0” encoding=“utf-8”?>. This tells the rest of the devices reading it the base coding that you are using.
In regards to MSACCESS I have not read how to get around this by setting the standard you wish to use. You can use the STRCONV() function to bring your code into the standard you wish.
https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/strconv-function
More reading:
What is ANSI format?
How to convert MS Access database encoding to UTF-8?
For a list of all the ASCII standards please see:
http://www.iana.org/assignments/character-sets/character-sets.xhtml
From Jim L answer and searched more info, I found the problem/solution. Return code will be correct, if I change System Locale to English.
Step to change system Locale
1. Control Panel
2. Region and Language
3. Administrative
4. Change System Locale to English
5. Restart computer
This is a solution. But, I cannot control each computer Locale and I cannot assume each computer Locale is English.
Related
I would like to determine the Thousand Separator used while running a VBA Code on a target machine without resolving to calling system built-in functions such as (Separator = Application.ThousandsSeparator).
I am using the following simple code using 'Format':
ThousandSeparator = Mid(Format(1000, "#,#"), 2, 1)
The above seems to work fine, and would like to confirm if this is a safe method of doing it without resorting to system calls.
I would expect the result to be a single char string in the form of , or . or ' or a Space as applicable to the locale on the machine.
Please note that I want to only use a language statement such as Format or similar (no sys calls). Also this relates to Thousands Separator not Decimal Separator. This article Using VBA to detect which decimal sign the computer is using does not help or answer my question. Thanks
Thanks in advance.
The strict answer to whether it is safe to use Format to get the thousands separator is No.
E.g. on Windows, it is possible to enter up to three characters into the Thousands Separator field in the regional settings in the control panel.
Suppose you enter asd and click OK.
If you now call Format(1000, "#,#") it will give you 1a000. That is only the first letter of your thousands separator. You have failed to retrieve it correctly.
Reading the registry:
? CreateObject("WScript.Shell").RegRead("HKCU\Control Panel\International\sThousand")
you get back asd in full.
To be fair, the Excel international properties do not seem to be of much help either. Application.International(xlThousandsSeparator) in this situation will return the separator originally defined in your computer's locale, not the value you've overridden it to.
Having that said, the practical answer is Yes, because it would appear (and if you happen to know for sure, please post an answer here) that there is no culture with multi-char thousand separator (even in China where scary things like 1億2345万6789 or 1億2345萬6789 exist, they happen to be represented with just one UTF-16 character), and you probably are happy to ignore the people who decided to play with their locale settings in that fashion.
I have an application which contains the line below to assign a parsed XML value to a variant array.
V(2) = latNode.Text * 1
This works fine on my system (Windows 7, Excel 2010) but doesn't work on some other system or systems - and I've not been able to get a response from the user who reported the problem.
I've switched out the offending line for:
V(2) = CDbl(latNode.Text)
This still works on my system, but then I had no problem in the first place. The question is on what systems does the first approach fail and why, and will the second method always work? I'm sure I've used the "String * 1" trick elsewhere before and would like to know how concerned I should be about tracking down other occurrences.
Thanks.
Maybe it's related to thousands separator and decimal mark. Office VBA uses cultural settings even in CDbl, in my German Excel version, it's reversed compared to English, CDbl("123.4") is parsed to 1234, CDbl("123,4") to 123.4.
Val(x) will always parse the dot as decimal mark.
I've looked into NSFormatter, NSNumberFormatter, and the other formatting classes, but can't find a build into solution. I need to format phone numbers depending on the country code.
For instance, for US, I get a string such as +16313938888 which I need to format to look like +1(631)393-8888. The problem is I need to do this for all formats. Netherlands, I receive a string +31641234567 which will be +31(6)41 23 45 67 (something like that).
Hardcoding for 200+ countries is too tedious and I really don't know all the format rules. Is there something in the docs I'm overlooking or does anyone know of an open source class that manages this?
See https://github.com/rmaddy/RMPhoneFormat for an iOS specific solution.
Try this Google solution - https://github.com/me2day/libPhoneNumber-iOS
They have ports for C++, Java, Objective-C and others.
Unfortunately iOS does not have any public APIs for this. You can try to integrate libphonenumber that is a complete implementation for parsing and formatting international phone numbers. It has a C++ version so theoretically you can cross-link with it.
You definitely don't want to hard-code all of the various country formats. There are typically 3-5 formats per country. Instead, use a format database (such as a plist) and write code to format the number based on the given country code.
A good international format property list 'UIPhoneFormats.plist' can be found here: https://code.google.com/p/iphone-patch/source/browse/trunk/bgfix/UIKit.framework/PhoneFormats/UIPhoneFormats.plist?r=7
In that list, '$' allows any character, '#' must be a number, and the '(space) ', '(', ')' and '-' are inserted between numbers. Non-numeric characters typed by the user hint to the desired format.
I've shared my phone number formatter class, inspired by Ahmed Abdelkader's work, at https://github.com/lathamglobal/iOS-Phone-Number-Formatter . It is a very small, single-class international phone number formatter that uses the plist just mentioned.
You can try this:
let phoneNumber : CNPhoneNumber
let digits = phoneNumber.performSelector("digits").takeRetainedValue() as! String
It gives you directly the string, without formatting, with the phone number. However if the number is saved with international prefix, you will have it also in the resulted string.
According to MSDN vb.net uses this extended character set. In my experience it actually uses this:
What am I missing? Why does it say it uses the one and uses the other?
Am I doing something wrong?
Is there some sort of conversion tool to the original character set?
This behaviour is defined in the documentation of the Chr command:
The returned value depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class in the System.Globalization namespace. You can obtain ANSICodePage by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
So, the output of Chr for values greater than 127 is system-dependent. If you want reproducible results, create the desired instance of Encoding by calling Encoding.GetEncoding(String), then use Encoding.GetChars(Byte()) to convert your numeric values into characters.
If you go up one level in the chart linked in your question, you will see that they do not claim that this chart is always the output of the Chr command:
The characters that appear in Windows above 127 depend on the selected typeface.
The charts in this section show the default character set for a console application.
Your application is a WinForm application, not a console application. Even in the console, the character set used can be changed (for example, by using the chcp command), hence the word "default".
For detailed information about the encodings used in .net, I recommend the following MSDN article: Character Encoding in the .NET Framework.
The first character set is Code Page 437 (CP437), the second looks like Code Page 1252 (CP1252) also known as Windows Latin-1.
I'd guess VB.Net is simply picking up the default encoding for the PC.
How did you write all this? Because usually, when you use a output stream function, you can specify the encoding going with it.
Edit: I know this is not C#, but you can see the idea...
You'd have to set the encoding of your filestream, by doing something like this:
Setting the encoding when creating the filestream
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar