Microsoft Visual Studio XAML UI Designer – kill, kill, kill

I’ve blogged before that in solutions that share xaml between DLLs the XAML UI Designer can cause problems by locking files and blocking builds. The fastest solution is usually to kill off the designer process. Here is a bit of powershell to do just that;

Get-Process -Name XDesProc | Stop-Process

Workaround for ListPicker missing writable ItemCountThreshold

The ListPicker in Wp7 Toolkit allowed you to specify how many items could be shown before it went into full-screen mode. Quite correctly that has been removed and is now hardcoded to 5. Well, rules are there to be broken, and if you *really* need to workaround the problem then you can try the following (it works at the moment, may not work in the future)

Type type = MyListPicker.GetType();
PropertyInfo itemCountThreshold = type.GetProperty("ItemCountThreshold");
itemCountThreshold.SetValue(MyListPicker, 20);

Looking at the reflection code I released that I hadn’t actually done anything sneaky. So I replaced it with the following…more graceful code;

MyListPicker.SetValue(Microsoft.Phone.Controls.ListPicker.ItemCountThresholdProperty, 20);

Klingon language on Window Phone

After a recent post about how to allow the Resource Manager to use a non-supported culture I wondered how difficult it would be to support the usual  localisation binding. So, in the great tradition of computer science I wanted to bind to Klingon. Whilst I can see that the correct solution would involve writing a custom tool I wanted a quick ‘hack’ and this is what I’m presenting here. To keep the post size down, I’m assuming you’ve followed the previous project and have that project available.

  1. Create the Klingon resx. Copy AppResource.en-GB.resx over to AppResources.klingon.resx
  2. Add the custom tool PublicResXFileCodeGenerator to AppResources.klingon.resx (see the properties of the file)
  3. Write some klingon – open the resx and change the ApplicationTitle to the following Klingon (it’s not rude) – TLHO’
  4. Create a new String Library class;
  5.  public class AlienLocalizedStrings
            private static AppResources_klingon _localizedResources; 
            static AlienLocalizedStrings()
                _localizedResources =  new AppResources_klingon();
                Type type = _localizedResources.GetType();
                FieldInfo info = type.GetField("resourceMan", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.SetField);
                info.SetValue(null, new AlienResourceManager("klingon"));
            public AppResources_klingon LocalizedResources { get { return _localizedResources; } }

  6. Add the resource to App.xaml
  7.     <Application.Resources>
            <local:LocalizedStrings  x:Key="LocalizedStrings"/>
            <local:AlienLocalizedStrings x:Key="AlienLocalizedStrings"/>

  8. Now you can bind to Klingon, e.g.

 <TextBlock Text="{Binding Path=LocalizedResources.ApplicationTitle , Source={StaticResource AlienLocalizedStrings}}" Style="{StaticResource PhoneTextNormalStyle}" Margin="12,0"/>


The solution works pretty well, obviously the string component is hardcoded to ‘klingon’ which isn’t ideal but I’m sure that can also be resolved with a little more effort. Enjoy Klingon on the phone Smile

Using a resource for an unsupported culture in Windows Phone

I was talking to a fellow dev about why the Resource Manager cannot support languages that the phone platform itself does not support. However, I thought that there probably would be a workaround…and here it is.

Step 1 – Create your basic project

Create phone project, by default this will create;


Step 2 – Add a test resource

Open the AppResources and add a new string called ‘ColourLabel’. I’m making the horrible assumption that you have defaulted to en-US so please enter the value of ‘Color’.

Step 3 – Add a new resource culture

Project->Add->Resource, e.g. AppResources.en-GB.resx

This should have copied our resource string from the master resource, so please change ‘ColourLabel’ to the correct spelling of ‘Colour’ Winking smile

Step 4 – Add a new unknown resource culture

Copy AppResource.en-GB.resx over to AppResources.en-XX.resx

Change ‘ColourLabel’ value from ‘Colour’ to our alien value of ‘ColourXX’

Step 5 – Change Build Action

If you try to use the ResourceManager to access en-XX it will fail because the culture is alien to the platform. So starts the workaround, change the BuildAction of en-XX to ‘Content’

Step 6 – Execute the resource manager

Running the following code…

AlienResourceManager britishResourceManager = new AlienResourceManager("en-GB");  
System.Diagnostics.Debug.WriteLine("en-GB: " + britishResourceManager.GetString("ColourLabel")); 
AlienResourceManager alienResourceManager = new AlienResourceManager("en-XX");  
System.Diagnostics.Debug.WriteLine("en-XX: " + alienResourceManager.GetString("ColourLabel"));  

results in the following output;

en-GB: Colour  
en-XX: ColourXX  

all done?

It’s fairly obvious that isn’t standard code, but it’s actually just a little over-riding of the standard ResourceManager. Here is my quick version, hope you find it useful.

public class AlienResourceManager : ResourceManager     
  private string alienCultureName;         
  private Dictionary alienStrings = null;         
  private CultureInfo currentCulture;         
  public AlienResourceManager(string alienCultureName) :  base("MyPhoneApp.Resources.AppResources", typeof(AppResources).Assembly)         
    this.alienCultureName = alienCultureName;              
      CultureInfo ci = new CultureInfo(alienCultureName);                 
      this.currentCulture = ci;             
    catch (Exception)             
      this.IsAlienCulture = true;             

  private void LoadAlienStrings(string alienCultureName)         
    var localisation = Application.GetResourceStream(new Uri("Resources/AppResources." + alienCultureName + ".resx", UriKind.Relative));             
    StreamReader resx = new StreamReader(localisation.Stream);             
    string resXml = resx.ReadToEnd();             
    XElement resourceFile = XElement.Parse(resXml);             
    this.alienStrings = new Dictionary();             
    var resourceStrings =              
      (from r in resourceFile.Descendants("data")              
      select new  { Name= r.Attribute("name").Value, Value = r.Element("value").Value}).ToList();              

    resourceStrings.ForEach(r => this.alienStrings.Add(r.Name, r.Value));          

  public bool IsAlienCulture { get; set; }          
  public override string GetString(string name)         
    if (this.IsAlienCulture)             
      return this.alienStrings[name];             
      return base.GetString(name, currentCulture);             

What is stored on the Windows Phone back stack?

Recently I was in a conversation about memory usage on the Windows Phone. The conversation turned to the Phone back stack and the question became, “what is stored on the back stack?” So I created a very simple application; MainPage.xaml allows the user to select and show a picture. It also contains a link to Page1.xaml. Page1 displays a count of the back stack plus a simple view model that contains a large chunk of dummy data and a creation timestamp. It also has a link to MainPage.xaml. To be clear, there is no code that reloads or stores/restores state, everything is creating either in the constructor or from user input. This allowed me to create a test with the following stack;

MainPage.xaml (pic1) –> Page1.xaml (Count=1) –> MainPage (pic2) –> Page1.xaml (Count=3), etc.

The results show that EVERYTHING is stored on the stack, user selected pictures, view models, everything . As you move back through the stack all the pictures and the old timestamps are all correctly displayed. The only limit on how big the stack can grow is the memory ceiling.

Resume and Tombstoned

Any Windows Phone developer will know the story isn’t as simple as that, what about Resume and Tombstone? If you have travelled through a number of pages and press the Windows key then your app will be deactivated. If you switch back to your app and the OS has allowed you to Resume then all of the state will be ready for you. The implication here is that your entire apps memory footprint can be hanging around until the OS decides you no longer want it. However, if your application is Tombstoned then only the navigation URI history is automatically retained. Consider the following stack with the selected picture and the view model timestamp;

Main Page (pic1) –> Page 1 (T1) –> Main Page (pic2) –> Page 1 (T2)

With a successful Resume you will be able to back-through the application and get;

Page 1 (T2) –> Main Page (pic2) –> Page 1 (T1) –> Main Page (pic1) –> Close

However, if your app is Tombstoned you will get;

Page 1 (T3) –> Main Page (empty) –> Page 1 (T4) –> Main Page (empty) –> Close

Therefore under Tombstoned conditions it is up to you to store and restore any state you wish to present to the user or even remove the back stack if that makes more sense.


If your application allows an ‘infinite’ stack to form then you should worry about the memory implications and consider using a strategy that will either/or prevent the stack growing too large or clear up resources as you navigate away from a page.

(Edit) What happens when you back-out through the stack?

One thing I didn’t mention was when are the pages fully destroyed? As you move away from a page (in either direction) the page unload is called, but the underlying object remains. As you move back through the stack the page objects are reclaimed. This will not necessarily happen immediately, but you should eventually see the destructors called for pages.

Binding tip, only create observable collection once

I thought I’d share a really silly mistake I’ve just made. I have a list selector that is bound to an observable collection in my view model. However, when I was adding items to the collection they were not showing in the list. The mistake I had made was that upon refreshing the list I was using collection = new collection, this breaks the binding. So ensure you only create your target collection and if you want to refresh it then use collection.Clear().


Phone development tip – disconnecting debug sessions?

Recently I’ve been asked to investigate a number of issues involving the Tombstone state. During the investigations I was using the ‘Tombstone upon deactivation’ and I was experiencing a number of lost connections between Visual Studio and the emulator/device. What I didn’t appreciate was these disconnections are almost always caused by a simple exception in the application. I.e. the app was failing because of a null exception which was causing the debugger to disconnect rather than break(). So my tips are;

  • If you get a disconnect, place breakpoints at positions *before* you expect to hit a problem area, do not rely on Visual Studio break-pointing and showing you the exception
  • Once you have a disconnect you will probably have to un-install the app from the emulator/device otherwise Visual Studio may not reconnect [Edit] I’ve also found that just directly launching the app from the emulator and then restarting the debug session also works. [Edit 2] Also engaging the lock-screen can also clear the problem. [Edit 3] Actually I think it’s just about waiting for a bit!
  • Test for Tombstone, it still exists!