Migrating to Mango – Developer View. Part 5 final

Last time we constructed an app that can enumerate all keyboards and apply each one to its own TextBox. Let’s test it.
I ran the app for the first time and got an immediate crash.
Ok, let’s look what the debugger says … it showed a crash in InputScopeName constructor. Because the code is correct, the only explanation is that some InputScopeNameValues are illegal.
Surprise, surprise… msdn says the opposite. But OK, I added try/catch around the InputScopeName construction and – in case of an exception – filled the TextBox with the text “Unsupported”. Next figure shows the result.

App testing all InputScopeNameValues

Ok, I had a WP7.0 app where I could test each and every keyboard. As next, I created an identical project and targeted it to WP7.1. Finally, I could start comparing WP7.0 vs. WP7.1.
a) Supported keyboards on both platforms
Both WP7.0 and WP7.1 show the same unsupported keyboards. You see all of them in the picture; the rest (more than 50 keyboards) work well.
WP7.1 offers two additional keyboards – NumericPassword and Formula. You won’t find them in msdn, but if you open InputScopeNameValue from metadata (context menu for “InputScopeNameValue”, then select “Go To Definition”), you will see this comment: “Do not use”.
Further, after opening all TextBoxes, it seems (I wouldn’t swear at it) that the only keyboards with different visual appearance are those with numeric character. (DateDay, DateMonth, DateYear, TimeHour, TimeMinorSec…)
b) What can be read from metadata
Above I explained how to get InputScopeNameValue definition from metadata. If you do the same in both projects, you can compare WP7.0/WP7.1 definitions of the enum. The comparison will confirm that the only difference are the two added scopes mentioned above – NumericPassword and Formula.
Except that there is just one subtle difference that I would overlook if both enums were not opened in a diff tool. It is this comment line for WP7.0
          // C:\Program Files (x86)\Reference Assemblies\ Microsoft\ Framework\                     Silverlight\v4.0\ Profile\WindowsPhone\ System.Windows.dll
which is replaced for WP7.1 by
          // C:\Program Files (x86)\Reference Assemblies\ Microsoft\ Framework\                     Silverlight\v4.0\ Profile\ WindowsPhone71\ System.Windows.dll
See the implication? Visual Studio links different phone dlls depending on the project target. (Compare to the Part 2, where I listed the folders where the phone dlls are installed.)
Here is a part of the enum definition from metadata:
          // Summary:
          // Do not use.
          NumericPassword = 56,
You see the constant definition – name (NumericPassword) and value (56) – this must be coming from the dll file.
Then you see the comment “Do not use”. You won’t find it in the dll file. (Logically – why would programmers documentation go to the phone device?) Instead, it is part of the related System.Windows.xml file. Every phone dll has one xml file and these xml files are used by the Intellisense. In other words, Visual Studio context help depends on the project target as well.
c) Running simultaneously WP7.0/WP7.1 apps on the emulator
While testing both keyboard apps they got simultaneously installed on the Mango emulator.
Now, when you run the WP7.0 app, it shows WP7.0 keyboards. And vice versa – WP7.1 app shows WP7.1 keyboards. On the same emulator!
For me this proves that the emulator behaves like Visual Studio – it looks at the app target (profile) and links dynamically to respective .Net assemblies.
Not that I would be surprised (I expected that), yet it pleases when your hypothesis gets confirmed.
About the author
Jan Slodicka
Programming for over 30 years. Covered several desktop platforms and programming languages. Since 2003 working for Resco on mobile technologies – Palm OS, Windows Mobile, Windows Phone 7, Android. You can contact me at jano (at) resco (dot) net.