Archive for February, 2008

Announcing the ChrisTec Managed Today Screen Framework

Wednesday, February 27th, 2008

I have had a lot of positive feedback about the early preview of my project to allow custom Windows Mobile Today Screen Items to be written in C# or VB.NET. In the past few days I have been working on formalising this project and putting some plans in place to further develop the concept.

Today I would like to announce that I have hosted the project on the CodePlex website. The framework is now available at

The CodePlex webpage for this project shows two additional releases (Alpha 1 and Alpha 2) since the proof of concept I demonstrated in my previous blog entry. One advantage of these new releases is that after bouncing some ideas around with Peter Nowak I have managed to significantly simplify the installation process for custom items.

To help promote this framework I have also put together the following screencast to help demonstrate how you can utilise the latest release to create your own custom today screen items in C# or VB.NET.

I would love your feedback on this screencast. Watching it myself it is clear that I need to improve my technique, but hopefully this will come with practice. It defiantly seems easier to demonstrate some things in video form rather than via words.

Creating Managed Today Screen Items

Sunday, February 17th, 2008

Screenshot showing sample today screen item written in C#Today I thought I would demonstrate a proof of concept that may enable you to create today screen items in managed languages such as C# or VB.NET. In part this early preview was brought about by a recent request for advice on how to create managed Input Methods for the SIP keyboard, something that I think could be achieved using a similar approach. This is still a work in progress to see what is possible…. at the moment I have not fully evaluated the technique to be valid and/or tidied the code to my usual standard for release. I would love your feedback on this project.

Problem Definition

The Windows Mobile OS has a Today Screen API that enables custom items to be displayed on the main screen of the device. This API is highly geared towards native (C or C++) developers, and it is not possible for managed (VB.NET or C#) developers to implement the API directly.

Jim Wilson previously demonstrated in an MSDN article titled “Creating a Pocket PC Today Screen Plug-in with the .NET Compact Framework” a technique were a C++ based today screen item was developed to display HTML based content that was generated by a C# application. Although this is suitable for some applications it doesn’t lend itself to highly interactive or graphic intensive animated displays.

What we ideally want to do is to implement a minimal amount of native code that satisifies the requirements of the Today Screen API and have this native stub delegate all the GUI functionality off to a managed application.

It would also be extremely handy if the native part of this solution could be written once and reutilised among multiple managed today screen items. In part because this would open up today screen item development to those developers who currently don’t have experience in developing native code.

Solution Architecture

Architecture of a managed today screen item solutionMy solution utilises a native today screen item written in C++. This today screen item is implemented in a DLL called ManagedTodayScreenItem.dll. The OS is configured to load this item into the today screen process. However unlike other today screen items this one looks up additional configuration data stored in the registry to determine the name of a managed (i.e. VB.NET or C#) executable that should be launched when it is first displayed.

The managed executable starts up as normal and displays it’s main form. However once displayed the managed process then proceeds to establish an inter-process communication (IPC) channel back to the native today screen item. Once this channel is established the managed application informs the native today screen item of it’s window handle. The native today screen item then reparents the managed form to be a child of the today screen item and resizes it to fit the space allocated to the today screen item.

From this point on the illusion of a managed today screen item has been made. Whenever the managed form needs to act like a today screen item (such as painting the today screen watermark on it’s background) it can communicate with the native today screen item stub, and conversely whenever the native stub detects a change in it’s size or location it can communicate this change back to the managed part of the item.

Creating a new today screen item

Creating a new today screen item with this framework is relatively easy. Perhaps the easiest way is to modify the SampleTodayScreenItem example within the sample application mentioned below.

If you are creating a today screen item from scratch you need to follow these steps:

  1. Create a new Smart Device Application (win forms project).
  2. Change the FormBorderStyle property of the main form to None. As discussed previously this enables us to make the form non fullscreen.
  3. Add a reference to the Christec.WindowsMobile.TodayScreen.dll assembly found in the sample project below.
  4. Change the main form to derive from the TodayScreenPluginForm base class.

The last step is very important. The TodayScreenPluginForm class itself derives from Form but overrides a couple of methods (such as OnPaint) to ensure the form has the look and feel of a today screen item. This base class also behind the scenes sets up the inter-process communication channel which allows the managed part of the solution to communicate with the native part.

Your form source code should look something like the following after these changes:

using Christec.WindowsMobile.TodayScreen;
public Form1 : TodayScreenPluginForm
  public Form1()
    : base(4567)

A key thing to point out here is the call to the TodayScreenPluginForm constructor that accepts an integer parameter. This integer is an id that is a unique value that identifies this particular today screen plugin. This is the part of the framework that enables the one native today screen item to be reutilised multiple times by different managed plugins (since each managed plugin should be given a different id value to differentiate itself).

Once the managed executable has been created as described above and compiled all that is required is a couple of registry settings to be added to make the operating system aware of the new today screen item. These registry settings are as follows:

Underneath HKLM\Software\Microsoft\Today\Items\<Name>

  • DLL = “\Windows\ManagedTodayScreenItem.dll”
  • Flags = 4567
  • Name = “A name for the item”
  • Options = 0
  • Type = 4

<Name> within the registry key above should be replaced with the name you want to be visible to the user within the Today Screen control panel applet. All these registry values should be identical for each managed today screen plugin you develop. The only difference should be the value you use for the Flags setting. This should match up with the value you passed into the TodayScreenPluginForm constructor within the source code of the managed part of your today screen item.

The native ManagedTodayScreenItem.dll today screen item utilises this “flags” value to lookup another set of item specific registry keys to determine which managed executable needs to be executed as outlined below:

Underneath HKLM\Software\ChrisTec\ManagedTodayScreenPlugins\<id>

  • (default) = “\path\to\managed\executable.exe”
  • Height = height of today screen item in pixels.

<id> within the registry key above should be replaced with the unique id value (4567 in the example) for your managed today screen item. At present it is not possible to dynamically change the height of the today screen item at runtime. This would be something that is reasonably easy to implement but is one of the features I have not implemented yet as it wasn’t required in order to prove the validity of the concept.

Sample Applicaton

[Download - 37.1KB]

The sample project that is available for download contains two CAB files within a subdirectory called “bin”. These are as follows:

  • – installs the native part of the today screen item framework. This part can be shared among multiple managed today screen items and only needs to be installed once per device. It can be thought of as being similar to the .NET CF or SQL Server CE CAB files that install a framework for other applications to utilise. This cab file can also be utilised by managed developers who are not comfortable rebuilding the C++ source code.
  • – An example today screen item written in C#. It simply consists of three buttons with each button displaying a simple message box once clicked.

If both of these CAB files are installed on a Pocket PC device and the device is then soft reset you should see the new today screen item appear.

If you would like to have a go at creating your own managed today screen item you should also find a pre-compiled copy of the Christec.WindowsMobile.TodayScreen assembly that you will need to reference within this directory.

Within the other subdirectory (called “src”) you should be able to find solution files that will enable you to rebuild the two CAB files mentioned above.

Outstanding Tasks

As I stated in the introduction, this project is an early proof of concept that I have decided to share early on in the hope that it helps a few people and perhaps gets a couple interested in contributing. Since the code is not fully released there are a number of known issues and outstanding tasks.

Some of these are as follows:

  1. Slight compatibility issues on Pocket PC 2003 devices after a soft reset.
  2. Does not handle the managed application crashing in the most robust manor.
  3. The Visual Studio IDE experience could be improved with project item templates etc.
  4. Having multiple managed today screen items share the single native dll probably doesn’t work (needs a little more work).
  5. The Christec.WindowsMobile.TodayScreeen assembly should be placed into the Global Assembly Cache (GAC).
  6. It would be great if less registry configuration is required.


Hopefully this blog entry will cause some interest, as I know developing custom today screen items in managed code is a frequent question on online developer help forums. Although this solution isn’t fully complete and isn’t the most straight forward to configure (at present at-least) the results I have managed to get so far are encouraging.

If this proof of concept can validate the technique I am using to host .NET Compact Framework based forms within native processes I can see no reason why it would not work in other situations such as custom SIP based keyboards. The only difference would be the native component that would need to wrap up the native API provided by the operating system.

I would be really keen to hear your feedback and thoughts on this prototype. Especially if you are able to give me a hand to further validate and develop the concept.

Summer Road Trip 2008 – Debrief

Friday, February 15th, 2008

Photo of the Christchurch leg of the Summer Roadtrip 2008 event.

The Summer Roadtrip 2008 organised by the New Zealand .NET User Groups arrived in Christchurch today.

There was a great turn out of approximately 150 people according to Darryl (the second highest turn out so far!). This wasn’t bad considering the dismal weather. We joked the event should have been renamed the “Winter Roadtrip 2008″…

Daniel Wissa was the MC for the event and did a wonderful job, plugging the Christchurch .NET User Group along the way. If you haven’t came along to the user group before I encourage you to come along to our next meeting, the more the merrier and the better events we can put on. We have a mixture of events during work hours and nights to fit in with most people’s schedules.

Chris Auld and Jeremy Boyd did an amazing job running the presentation, especially considering that Chris wasn’t feeling too well. I was the local speaker and covered using Visual Studio 2008 to develop and debug ASP.NET AJAX functionality. I would really like to thank JB for making it really easy for a newbie presenter to learn the ropes and feel comfortable on stage.

I think I have caught the presenting bug and helping present this event defiantly hasn’t put me off. If anything it has shown me how expertly Chris and Jeremy can present technical content and given me some things to work on in developing my own presenting skills. I look forward to taking the opportunity to present more in 2008 and grow as a presenter. If you have a presentation opportunity, please feel free to contact me.

If you are keen to take a look at the source code or slides for the summer road trip presentation, these will be posted after the last presentation in Invercargill (i.e. in a couple of weeks time). So if you were keen to take a look for yourself at how little code you have to manually write to communicate with your WCF services via javascript stay tuned, and I’ll post the download location in due course.

Improving Comboboxes on Smartphone devices

Monday, February 11th, 2008

Screen real-estate is at a premium on smaller Windows Mobile smartphone devices, so it is important to maximise the use of every available pixel in conveying useful information to the user. This blog entry demonstrates a technique to maximise the usability of combo boxes within .NET Compact Framework applications by reusing some of the existing screen real-estate.

Defining the problem

When you place a Combobox control on a form within a Smartphone application you get a control which shows a single item with left/right arrows that allow you to scroll through the list of options.

As an alternative if you press the Action key (middle of the D-PAD) on the combobox the full list is displayed in a fullscreen window. This window however is always labelled “Select an Item”. Because the window is fullscreen it is possible for the user to loose context (they can’t see any labels etc you have placed on your form), and forget what they are meant to be selecting. What we would like to do is to replace the “Select an Item” title with something more appropriate for the current field.

A screenshot showing the behaviour of a standard combo box when in fullscreen mode A screenshot showing the behaviour of your modified combo box when in fullscreen mode
What we get by default What we desire

Developing a solution

This is where having knowledge of the underlying native (C/C++) APIs that implement Windows Mobile is useful. When targeting a smartphone device a .NET Compact Framework Combobox control is actually implemented via two separate controls as far as the operating system is concerned, a 1 item high listbox coupled to an up/down control. The native Win32 smartphone documentation calls this type of configuration a Spinner Control.

Screenshot of Remote Winspy application showing the native windows associated with a combo boxBy using a utility included with Visual Studio called Remote Spy++ we can see this collection of controls. In the screenshot to the left you can see that one of the combo boxes in the sample application is selected, and underneath it you can clearly see the listbox and up/down (msctls_updown32) controls it is made up of.

In order to change the title of the popup window associated with a combo box we need to:

  1. Find the native window handle for the up/down control
  2. Change it’s window title to the desired prompt text

The ComboBox class has a Handle property that returns a native window handle (HWND) that is associated with the managed control. For a ComboBox the Handle property actually returns the handle of the listbox control and not the parent “NETCFITEMPICKERCLASS_A” control as may be expected. This was probably done for native code interop compatibility reasons. So to find the native window handle of the up/down control we simply need to find the handle for the window immediately after the window returned by the ComboBox.Handle property.

Once we have found the window handle for the up/down control we are finally ready to replace the popup window title. According to the Spin Box Control documentation, the popup window title comes from the title of the up/down control, and it defaults to the “Select an Item” prompt if a title isn’t specified. We can change the title of a native window by calling the SetWindowText API.

All these individual steps can be wrapped up into an easy to call method as follows:

using System;
using System.Windows.Forms;
using System.Runtime.InteropServices;
public static class ComboboxExtender
  public static void SetPromptText(ComboBox combo, String text)
    // Obtain the native window handle of the up/down spinner control
    IntPtr hWndListBox = combo.Handle;
    IntPtr hWndSpinner = GetWindow(hWndListBox, GW_HWNDNEXT);
    // Set the title of the spinner
    SetWindowText(hWndSpinner, text);
  private static extern bool SetWindowText(IntPtr hWnd, String lpString);
  private static extern IntPtr GetWindow(IntPtr hWnd, UInt32 uCmd);
  private const UInt32 GW_HWNDNEXT = 2;

Sample Application

[Download - 16KB]

The sample application available for download demonstrates using the ComboBoxExtender class developed above. The interface consists of two combo boxes which have been configured identically. The first combo box shows the default prompt text, while the second has had its prompt text replaced via a call to ComboBoxExtender.SetPromptText within the Form’s Load event handler as shown below:

ComboBoxExtender.SetPromptText(comboBox2, "Select Car Colour");

I am a stickler for improving the quality and polish of Windows Mobile applications. This tip is a very minimal code change that can be implemented quickly, yet can have a profound impact on the usability of your application if it is full of combo boxes. A similar trick can also be implemented for Expandable Edit controls.

If you are developing .NET Compact Framework applications that target the Windows Mobile Smartphone (Standard) platform, I seriously encourage you to consider making this usability change to your applications.

Community Interview: João Paulo Figueira

Thursday, February 7th, 2008

Photo of João Paulo Figueira1) Who are you? Where are you located etc?

My Name is João Paulo Figueira, I am 42 years old, married and father of two girls. I live in the northern outskirts of Lisbon in a small town that marks the border between the city and the countryside. I work for my own company where I develop software for Windows mobile and embedded devices and the occasional desktop project.

2) On your blog you mention that you have been writing software for mobile devices since 2002, and have became “totally addicted”. How did this come about?

It’s not difficult to get addicted to writing code for these devices. Back in 2002 everything was still very new and most users would look at a Pocket PC device as an “agenda” or digital organizer. Almost nobody grasped the full potential of the devices, especially on the data storage and processing perspectives. When I started writing code back then, I spent most of my time writing proof-of-concepts and demos to prove to potential customers the power of such a small device. Interestingly I started working with Pocket PC devices when the Internet bubble bust hit the company where I was working and was forced to leave. After some years working in marketing and management positions, I had to resort to the first useful skill I had ever learned: developing in C++.

3) You run a company called PrimeWorks. On the company website there is the tag line “remote access to mobile databases”. What services/products do you provide?

Right now Primeworks has only one worker: me. I started the company to provide custom software solutions to the local market in partnership with the local heavyweights that had little to no competencies in the area. Database development was already a very hot topic and I started to approach it using the ADOCE objects. This approach proved to be short-lived because Microsoft discontinued the support for ADOCE with the Pocket PC 2003 platform. There was no other way to access the SQL CE databases other than by using OLE DB. This was when I started to work on adapting the ATL OLE DB Consumer Templates to work on the Pocket PC. In 2004 I got my first MVP award and went to my first MVP Summit where I realized that there was a shortage of tools for the SQL CE database, especially on the remote access and data import and export. Later that year I published the first version of Data Port Wizard, a tool to transfer data between desktop Access databases and SQL CE databases on a device connected via ActiveSync. Since then I have improved this code and spawned other products. Besides DPW, I am now selling two other major products: Data Port Console and DesktopSqlCe. The Console allows users to manage all versions of SQL Compact (2.0 through 3.5) databases from a single desktop application. DesktopSqlCe is a .NET 2.0 assembly that implements all the remote data access classes as an ADO .NET provider. With this library you can write desktop .NET applications that access all versions of SQL CE databases either on a remote device or on the local disk. Occasionally I also write high-speed data transfer tools for customers who want to develop their own corporate data synchronization scenarios. When I’m not doing all of this, you can find me providing consulting services for a GPS manufacturer.

4) Since starting your blog in April 2005 you have mainly covered native development topics. What leads you to focus on native development instead of the .NET Compact Framework?

First of all, native code is my passion. Second, I believe that native code is still the only solution for a large number of problems, especially when performance and resource usage are an issue. Finally, it’s downright fun and challenging. I believe that there is a lack of development resources for embedded and mobile native code developers and the demand for these skills has not diminished. Just look at the MSDN and PocketPCDN forums… There are lots of people still developing in C and C++ for devices and they need all the resources they can get. I just want to help them with my own experiences.

5) One of your goals for 2008 is to develop a replacement for the ATL OLE DB Consumer Templates. This was an easy way for native developers to access databases such as SQL Server Compact Edition but has progressively became unsupported by Microsoft. Do you find that as Microsoft’s focus shifts to the managed environment, that native development has began to suffer?

Microsoft seems to be shifting back a little bit to supporting native developers, at least on the desktop. If you look at the latest developments on the desktop MFC library, you can only infer that C++ is not being written off. I still have to understand what Microsoft plans to do with native code for devices, and I actually plan to ask them about this next April at the MVP Summit. Native code is needed for a number of solutions – take my own products. High data transfer speeds are achieved by using the low-level OLEDB interfaces and by mashalling the data between the desktop and the device in the native binary format. Does this mean that you must write your mobile sales application in C++? Surely not. How do you decide when to go managed or native? Just ask one question: where do I need the speed – development or execution? Not surprisingly you will find that the best approach is a mix of both, as most of my products illustrate.

6) Do you carry a Windows Mobile powered PDA or Smartphone with you?

Right now I’m carrying an HTC S620 Smartphone with Windows Mobile 6. It’s a very nice device with two very big problems: the battery cover tends to open and the device tends to fall to the ground very often (a design issue, maybe?).

7) Windows Mobile has came into some criticism lately with respect to the look and feel/usability of it’s UI when compared to devices such as Apple’s iPhone, with Microsoft promising significant improvements with Windows Mobile 7. Do you have any opinion on this debate? You have done some work in this department with respect to your list based form and carousel menu custom controls.

After using Nokia phones for several years, I can say that the Smartphone UI is still a bit crude although I did see some improvements when the S620 was upgraded to WM6… There are lots of rough edges on the UI design that have been dealt with very nicely by Nokia. I have never used an iPhone but did see some demos of it in action. It seems to be a very nice device for consumers, but I would like to see it prove itself running custom-made business applications. Microsoft surely did score here.

8) You are a Microsoft Most Valuable Professional (MVP). How did you become a MVP and what do you find the most rewarding aspect of being an MVP?

I became an MVP in 2004 mainly because of my articles on CodeProject and PocketPC Developer Network. This is still my major contribution to the community, although I also answer questions on community forums. Sometimes I get ideas from the forum’s questions to write my articles. Right now, I’m working on an implementation of a “collapsible toolbar” for the PocketPC, as requested by a PPCDN forum reader. There are a couple of things that make being an MVP very cool. On the top of the list is the recognition you get from Microsoft and the opportunities to network with the development teams and other MVPs. This gives you access to first-hand information about the new products, and probably the highest-skilled problem-solving network in the world. The complimentary MSDN subscription is also a very nice thing.

Summer Road Trip 2008 has began

Wednesday, February 6th, 2008

Chris, JB and Darryl have began their country wide road trip with well received events in Auckland and Tauranga. There’s still time to register for the other regions. So if you want a neat introduction to the “big three” Microsoft software releases of 2008 (SQL Server 2008, Visual Studio 2008 and Windows Server 2008) make sure you come along.

In the mean time I better prepare for my part of the presentation in Christchurch on Friday next week, and you can follow their progress around the country with regular updates and photos being posted on the Summer Road Trip website.

How to avoid hardcoding file paths within CAB file registry settings

Monday, February 4th, 2008

Screenshot showing Registry Editor window within Visual Studio

Sometimes when building a CAB file it is desirable to add registry values that refer to the location of files installed as part of the application. For example a document orientated application may configure file association registry entries that need to specify the location of the main executable.

The problem with hard-coding a registry value such as “\Program Files\MyApplication\MyApplication.exe” is that it breaks if the user chooses to install the application onto an SD Card, or the directory “\Program Files” is localised into some other name on a non English device. Ideally we would specify the registry value in such a way that it automatically adapts itself as part of the installation process. We can actually achieve this…

The Smart Device CAB project type within Visual Studio is a wrapper around the cabwiz.exe command line application. Behind the scenes the Visual Studio IDE takes all the settings you configure graphically, produces an *.INF file and passes it through cabwiz.exe. This means that the Visual Studio IDE supports many of the “power features” of the underlying tool.

One of these “power features” is the concept of Macro Strings. If you specify a registry value to be a string that contains the %InstallDir% macro the CAB installation process will automatically replace the %InstallDir% part of your string with the user’s specified installation directory.

As well as %InstallDir% there are a range of other macro strings which can be utilised as summarised in the table below:

Macro Substitution on English devices
%InstallDir% [directory application installed into]
%AppName% [name of application]
%CE1% \Program Files
%CE2% \Windows
%CE4% \Windows\StartUp
%CE5% \My Documents
%CE8% \Program Files\Games
%CE11% \Windows\Start Menu\Programs
%CE14% \Windows\Start Menu\Programs\Games
%CE15% \Windows\Fonts
%CE17% \Windows\Start Menu

Incidentally this feature is also the cause for a possible error message you may run across if you attempt to specify a registry value that contains an embedded % character…

“The Windows CE CAB Wizard encountered an error. See the output window for more information.”

Error: unsupported DirID 0
Error: File c:\xyz.inf contains DirIDs, which are not supported

This cryptic error message results from cabwiz.exe attempting to interpret the % character as a macro string. The solution to this problem is to escape single % characters with a second %. For example the value “100%” needs to be specified as “100%%”.