Error Code 0x80073CF9

After the latest build of Windows 10 mobile I noticed that my app freeze on the splash page. I tried to re-install it but it failed with the error code 0x80073CF9. I changed setting for touch and then I miraculous manage to install it. The problem with the splash still remained, so I uninstalled the app again so that I could run it in debug mode from Visual Studio. In the development environment the app worked, so I wanted to download it once more from the store. But guess…. same error code and previous workaround didn’t work. Version is based on Silverlight which Microsoft is moving away from. Maybe the problem is related to this technology. I’m currently working on porting it to UWP but isn’t ready to release version yet. When it comes to version it looks like an issue that Microsoft should look into. The app worked on pervious build so to say. Will spend some time to investigate and see if I can find any solution or workarounds, but currently it looks bad for version I hope I can release version in August. Stay tuned!

Culture Aware Validation

It is easy to display a decimal number for any culture in .Net. The formatting support is very comprehensive and you can fine tune it in a number of different ways to suite your particular needs. But how is it to validate a string representing a decimal number from potential any culture with a wide variety of formatting rules? For example, the following strings are the same decimal value displayed according to different cultures: 1,234.56, 1.234,65, 1 234.56 and 1’234.56

In C# I can use the Parse or TryParse method of the numeric type. I tried these for decimal numbers and noticed some unexpected behavior. For the “en-US” culture the decimal separator is a dot. When parsing the string “1.2”, I received the decimal value 1.2, but when parsing “1,2” the function returned 12! I was expecting an error for this string and wonder why I received a value 10 times time greater than the one I intended to write?

After some investigation I learned that comma is the group separator and can be used in an arbitrary way, for example the string “,,,1,,,2,,,” will also be evaluated to 12. I was not so comfortable with this and from my perspective a valid decimal string should look like the formatted string you receive from, for example, the ToString method.

When the framework doesn’t give you the support you want, you have to implement it yourself. I wanted to use a regular expression to validate decimal numbers from any culture in a stricter way. The difference between different representations is the sign for decimal and group separator. .Net framework includes functions that returns current cultures signs. My solution was to create the regular expression dynamically so I could build it during runtime for the culture in use.

string groupSeparator = Thread.CurrentThread.CurrentUICulture.NumberFormat.NumberGroupSeparator;
string decimalSepartor = Thread.CurrentThread.CurrentUICulture.NumberFormat.NumberDecimalSeparator;
string regularExpression = @"^\d{1,3}([" + groupSeparator + @"]\d{3})*([" + decimalSepartor + @"]\d+)?$";

Actually, I’m a bit reluctant to create my own regular expression, since I’m not sure I know all different formats. It is also easy to make a mistake and preferable I would like to use what is include in the framework. If I find a better way, I will use it instead!

Numeric Keypad in WP 8.1

Received my first support case on my app last week. A user from Russia couldn’t create an expense. To me a bit surprising, since it has been used for a couple of years and no one else have had this issue (to my knowledge). I asked him to write down step by step what he did. When I tried the same procedure, I couldn’t re-produce the problem. It worked very well on my mobile. He mailed me a video showing exactly what he did to make the app crash. This was video was extremely helpful and I immediately suspected what the problem could be. The format of number wasn’t consistent; it was displayed with a comma as decimal separator but he entered it with a dot as decimal separator.

In the page where the problem occurs, I use TextBoxes for numeric fields. A nice feature of TextBox is that you can set the type of input with a parameter called InputScope. This property determines which keyboard layout will be used when the user enters a value. I use Number which let the user to enter values with a numeric keypad.

When have tested my app I have always had a keypad with the right sign of the decimal separator. I have tested the app in a couple of different languages but never had a keypad with wrong decimal separator (unfortunately).

My first question was how do I select which decimal separator sign should be on the keypad? I couldn’t find any API so currently I don’t know how to do it from the code (if anyone knows, please leave a comment). I found out two other ways:

  1. Change keyboard in phone settings.
    By selecting a keyboard for a language that uses another decimal separator I managed to change it.
  2. Long tap on the decimal separator.
    If you long tap the decimal sign, you get a box where you can select which sign to use. You can also select the minus sign if you want to enter a negative number.


The work around for my user was to long tap and select the right decimal separator. While testing this, I realized that many of my users might very well have a keypad with the wrong decimal separator as default. I also found it a bit awkward to enter a decimal separator with long tapping, so in my next version I will simply this.


From the build event earlier this year I heard about a tool, Mobilize.NET, too relieve the work load to migrate an app from Silverlight to UWP. There is a good web cast from channel 9 about it at I really liked the idea even though I suspected that the tool wouldn’t be able to convert so much of my app. But just to get some help with some well-known common tasks sounded very helpful. So I installed it and gave it a try.

There were many issues reported and it would take very long time to sort things out (if even doable). As I looked through the converted code I realized that I’m just trying to port the code. My current implementation is just intended as an app for windows phone. It’s not designed as a universal app capable of running on several different devices.

I wanted to change this! Instead of just porting my “windows phone 8.1-ish” user interface to the universal windows platform. I wanted to re-design it so it becomes “universal-ish” and able to run on several different devices, primarily desktops and phones. Also, cross-platform in the long run.

Didn’t get so much help from Mobilize.NET and now my next challenge is to find a universal user interface, easy to use, implement and maintain for all different kind of devices…. Let’s see what I will end up with.