I am working on a project for my company, and while tracing previously written code I came upon this:
<value>A payment authorization for {0:C} has been received.</value>
What does {0:C} mean? I have been trying to find out and am having no luck.
This is just a string like any other string. Once loaded into memory, it will be used as the format parameter to string.Format. {0:C} just means to format the number as currency using the current UI culture (or is it just current culture? I can never remember).
It's formatting a number as currency.
Related
I have a software developed in C#, which is a pure sentefic application. Howver the German users found this software stopped working from time to time, when it is installed on German computers. The temporary solution is to change the Language setting in the control panel, and it works fine after we change the language setting from German to English. This is just a kind of engineering sofware, and the software have nothing relalted to the German or English language. Also, as suggested from other posts in msdn, I have checked the "InitializeComponent()" in the source does several times. There are not strange codes in the "InitializeComponent()" function.
When you change locale, you change the meaning of ',' (comma) and '.' (full-stop) when used in numbers. Could it be that you are trying to parse text containing these characters into numbers?
Does your program attempt to initialize numeric fields with formatted numbers, perhaps?
You need to make sure that your code is sensitive to the user's culture when parsing and formatting text. You also need to make sure you use a consistent culture (e.g. the InvariantCulture) when reading data stored to file or sent over a network.
If you are using .NET Framework 4.5, you might be interested to read about the CultureInfo.DefaultThreadCurrentCulture Property.
In the .NET Framework 4 and previous versions, by default, the culture
of all threads is set to the Windows system culture. For applications
whose current culture differs from the default system culture, this
behavior is often undesirable.
The examples and their explanations on the page could be quite helpful for your issue.
Also, as a side note, try{...}catch{...} blocks are always welcome.
I am building a multilingual web app. The client requires the site for HK to be displayed in English. Unfortunately, "en-HK" is not a valid culture in asp.net, so I tried to get around it using "zh-hk". However, this caused the date time strings (with format of dd-MMM-yyyy) to be displayed in Chinese.
Is there any way to display the language in english but localise it to Hk?
CurrentUICulture controls selection of localized resources: set it to an English culture (e.g. "en" or "en-GB").
CurrentCulture controls number and date formats etc., including day and month names. Either set it to "en-GB", or set it to a custom culture based on "en-GB", but with any modifications you want (e.g. your post suggests you want "-" as date separator: dd-MMM-yyyy).
Neither of these affects time zone etc, so I don't really see why it would be a problem simply to use "en-GB".
I don't know much about Hong Kong but given its recent history, the English language conventions used there are probably based on UK English rather than US English. The short date format used in Hong Kong (documented on Wikipedia here) certainly appears to support this assertion: it's day/month/year (British style, unlike the US style where it's month/day/year).
You could always create a custom culture (supported by Windows 7 onwards) for en-HK. This is done by using the CultureAndRegionInfoBuilder class and will allow you to create your en-HK CultureInfo, based on the en-GB culture if my comment above is correct. This would allow you to customize some of the elements of the CultureInfo if you wish to (and more importantly, if you know what is different in Hong Kong). By basing your custom culture on en-GB, your date formats will show month names in English. But creating a custom culture is probably overkill.
More simply, you could use the en-GB Culture name. Your app probably doesn't use some of the more arcane things in the en-GB culture that wouldn't apply to Hong Kong.
Note: In case there is any confusion, for date formatting Thread.CurrentUICulture has no effect whatsoever--it's entirely dependent on what Thread.CurrentCulture is set to (and which must be a specific culture, unlike CurrentUICulture for which a neutral culture such as "en" is OK).
As far as I know you can't combine your culture strings yourself (meaning, en-HK is not valid unless it is listed in .NET).
However, they have two different culture settings per thread:
System.Threading.Thread.CurrentThread.CurrentCulture
System.Threading.Thread.CurrentThread.CurrentUICulture
Which both controls different things. Maybe that can let you use english as language but HK as localized formats.
You could also override the formatting of dates and such specifically, and maybe find better cultureinfos that will give you the date format that you need.
I have a report choosing start date and end date.
I tested at the office and it is working fine.
When it is installed at the user's place, the following error pops up.
I wonder why is that?
I bring back the database and run at the office.
Still working fine.
Well, it's not a parsing problem in DateTime.Parse, which is what I first expected. Your code (Form1.Calculat) is calling the constructor directly, so you should be able to log what values you're trying to use to create the DateTime, along with which row of the database is causing the problem.
We can't really do any of that diagnostic work for you, but once you've worked out what the values are, you should look through your code to work out where they're coming from.
Does your client have a different default culture to your development machine? That's normally the first port of call - but unless you're manually parsing date/time strings into their constituent bits, I wouldn't have particularly expected this failure mode.
If you could post some code, that would really help.
Are you passing the values to the TimeToTicks method ?
Probably these values are not forming a valid DateTime. Why it works on your office PC might be because you have different culture settings.
For example, in one culture "11/25/2010" is a valid date as the format (MM/dd/yyyy), but on a different culture, where date format is set as (dd/MM/yyyy) it will not be a valid date.
You can change the system date format from the control panel or modify your code accordingly. Hope this helps.
I think it is most of a problem Culture specific rather than any other issue. At one system the date format would be MM/DD/YYYY and at other system it would DD/MM/YYYY or something like that. So the datetime object should be picked culture specific and values should be passed that way as well.
Hope it fixes the problem.
I would like to put the date the application was built somewhere in the application. Say the about box. Any ideas how this can be done? I need to do this for C# but I am also looking for a general idea, so you can answer this for any specific language other than C#.
Typically we just go with the executable's last modify date. This will be set when the exe is built and usually never changes (short of someone actually editing the file). When the file is installed, copied, moved, etc, Windows doesn't change that value.
DateTime buildDate =
new FileInfo(Assembly.GetExecutingAssembly().Location).LastWriteTime;
We use this technique for the about dialogs in our C# and C++ apps.
The third number of the assembly version is a julian date with 0=1 Jan 2000 if you're using [assembly: AssemblyVersion("1.0.*")]
e.g.
DateTime buildDate = new DateTime(2000,1,1).AddDays(
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Build
);
You should be using version control - Subversion is free. Then you could include a number from the version control system that would unambiguously identify the source code used to build the app. A date won't do that. There are other advantages too.
Full history of all changes to the project.
Work seamlessly with other developers on the same project.
EDIT: Nikhil is already doing all this. But for some incomprehensible reason he has been told to include the date as well. I'm going to leave this answer here anyway, for future readers of this question.
There are usually keywords in your source code control system for this sort of thing.
Otherwise, look at including the date and time in the version number, or simply creating a small source code file which contains the date and time, and gets included in the build
I have a system which is using phone numbers as unique identifiers. For this reason, I want to format all phone numbers as they come in using a normalized format. Because I have no control over my source data, I need to parse out these numbers myself and format them before adding them to my DB.
I'm about to write a parser that can read phone numbers in and output a normalized phone format, but before I do I was wondering if anyone knew of any pre-existing libraries I could use to format phone numbers.
If there are no pre-existing libraries out there, what things should I be keeping in mind when creating this feature that may not be obvious?
Although my system is only dealing with US numbers right now, I plan to try to include support for international numbers just in case since there is a chance it will be needed.
Edit I forgot to mention I'm using C#.NET 2.0.
You could use libphonenumber from Google. Here's a blog post:
http://blog.appharbor.com/2012/02/03/net-phone-number-validation-with-google-libphonenumber
Parsing numbers is as easy as installing the NuGet package and then doing this:
var util = PhoneNumberUtil.GetInstance();
var number = util.Parse("555-555-5555", "US");
You can then format the number like this:
util.Format(number, PhoneNumberFormat.E164);
libphonenumber supports several formats other than E.164.
I'm currently involved in the OpenMoko project, which is developing a completely open source cell phone (including hardware). There has been a lot of trouble around normalizing phone numbers. I don't know if anyone has come up with a good solution yet. The biggest problem seems to be with US phone numbers, since sometimes they come in with a 1 on the front and sometimes not. Depending on what you have stored in your contacts list, it may or may not display the caller ID info correctly. I'd recommend stripping off the 1 on the phone number (though I'd expect most people wouldn't enter it in the first place). You may also need to look for a plus sign or country code on the front of international numbers.
You can check around the OpenMoko website, mailing list, and source control to see if they've solved this bug yet.
perl and rails examples
http://validates-as-phone.googlecode.com/svn/trunk/README
http://www.perlmonks.org/?node_id=159645
Just strip out any non-digits, possibly using a RegEx: [^\d]
The only exception might be if you want to handle extensions, to distinguish a number without an area code but with a 3 digit extension, or if you need to handle international numbers.
What you need is list of all country codes and start matching your string first few characters against list of country codes to make sure it's correct then for the rest of the number, make sure it's all digits and of proper length which usually varies from 5-10 digits.
To achieve checking against country codes, install NGeoNames nuget which uses website www.geonames.org to get list of all country codes to use to match against them.