Who says I don’t know anything about Culture

I’ve just had a good dose today, because I got bit doing some csv export for a customer in Germany.  As a dyed in the wool C++ programmer, the move to C#/.NET contains a few unexpected gotchas.
Today’s?  The culture used by string.Format() isn’t at all like the one used by sprintf.
It turns out that though they both use the current culture/locale for the thread, in C++, that’s set to the C_LOCALE, whereas in C#, it’s set to the current culture of the operating system.
So in France for example, 1,000.45 gets printed like this: 1 000,45
That’s really going to mess up your CSV.
Of course, you can specify a culture in every print, but really, who’s going to remember to do that, and even then I haven’t checked if it gets passed down to the ToString method when formatted as {0} with no specifier.
So, I really need to do something like this:

CultureInfo ciEntry = Thread.CurrentThread.CurrentCulture;
Thread.CurrentThread.CurrentCulture = new CultureInfo(String.Empty);

// do my culture invariant work here...

Thread.CurrentThread.CurrentCulture = ciEntry;

And, remember to do it on thread pool methods too, because who knows what Culture they were last looking about.

Where did my resources go

I have been trying to understand the correct way to set my DataContext.  I have been doing it in code behind, but have been looking for a better way to do it with DataBinding.

Yesterday, I tried adding it to my local resources in my App() constructor, like this:

Resources.Add("MyGlobalViewModel", mgvm);

My application also had some resources defined in a ResourceDictionary in it’s own xaml file.

Unfortunately, I chose to add my resources in code before I called InitializeComponent(), and as a result, my additions were removed.

Once I did that I was able to set my data context as

<… DataContext={Binding {StaticResource MyGlobalViewModel}} … >

Tombstoning and Trial Mode for Window Phone 7

Yesterday, I attended the Windows Phone developer camp in London, courtesy of Microsoft.  I took the opportunity while there to add trial functionality to my two existing WP7 apps.

I based my code on the information found here:

http://msdn.microsoft.com/en-us/library/hh286402(v=VS.92).aspx

I naively bound some of my UI elements to be visible when the Trial Mode flag was set.  Because I was running in the debugger, and I tried to purchase the application, my app was tombstoned.  When the app is resurrected, Trial Mode defaults to true.

However, my debug version prompts as to whether to run in TrialMode or not, and as a result when the app is resurrected, it has already bound to the TrialMode flag.  Therefore you must implement INotifyPropertyChanged to broadcast the information.

WPF/Silverlight quirks

 

I’ve been trying to share some code between some of my projects, and occasionally struggle to get things to work.

Today, I moved some data binding from my WPF project to my Silverlight project.  The WPF project was using a string indexer on the current DataContext like this:

{Binding Path=.[version]}

This page:

http://msdn.microsoft.com/en-us/library/system.windows.data.binding.path.aspx

states

Optionally, a period (.) path can be used to bind to the current source. For example, Text="{Binding}" is equivalent to Text="{Binding Path=.}".

Silverlight on the other hand does not like the leading period, but works correctly (as does WPF) when specified like this:

{Binding Path=[version]}

Moral of the Story:  Don’t use leading periods.

VS2010/WiX Porting issues

Upgrading some old VS2005/Wix 3.5 projects to the new compiler raised some issues:

WiX gave some build errors described here:

http://sourceforge.net/tracker/index.php?func=detail&aid=3293788&group_id=105970&atid=642714

this was also set incorrectly in my wixproj file:

<WixToolPath>$(ProgramFiles)\Windows Installer XML v3.5\bin\</WixToolPath>