Archive for September, 2008

Intercept SMS messages

Tuesday, September 23rd, 2008

Screenshot of SMS Device Control sample applicationMany TV game shows use SMS text messages for viewer voting and other forms of participation. This blog post discusses how a Windows Mobile application can automatically respond to incoming SMS text messages to create such services.

Creating a Message Interceptor

The first step in catching received SMS text messages is to create an instance of the MessageInterceptor class that lives in the Microsoft.WindowsMobile.PocketOutlook assembly. You need to be careful about where you define this instance as if it goes out of scope and is garbage collected the message interception will stop.

MessageInterceptor interceptor =
  new MessageInterceptor(InterceptionAction.NotifyAndDelete);

An InterceptionAction is passed to the constructor. This parameter defines the behaviour which occurs when a message is received. The two options are:

  • Notify – The message interceptor gets a chance to process the message but it is also received by the standard SMS inbox application.
  • NotifyAndDelete – The message does not become visible to the user and is only seen by the message interceptor.

Specifying an interception condition

A message interceptor that processed and potentially deleted every message would not be very useful. You can define a message condition to reduce the number of messages caught by a message interceptor.

interceptor.MessageCondition = new MessageCondition(
  MessagePropertyComparisonType.StartsWith, "CKF:");

A message condition describes a MessageProperty (such as text message body or sender’s phone number) that should be compared against a specific value. A MessagePropertyComparisionType (such as Contains, EndsWith, StartsWith, or Equal) defines how to perform the comparison.

Only SMS text messages that pass the comparison will be forwarded to the message interceptor. In the code sample above, our message interceptor will intercept any message that begins with the special prefix “CKF:”. Any SMS message that does not match this condition will be placed into the standard SMS inbox.

Transient Interceptors

Now that we have configured the message interceptor we can finally request that it listens for incoming SMS text messages. We do this by registering a MessageReceived event handler.

interceptor.MessageReceived += SmsInterceptor_MessageReceived;

When we no longer desire to listen to incoming SMS text messages we simply remove our event handler.

interceptor.MessageReceived -= SmsInterceptor_MessageReceived;

When the last event handler unhooks itself from the MessageReceived event the message interception process will be disabled.

While enabled any received text message will be passed to our MessageReceived event handler for processing.

void SmsInterceptor_MessageReceived(object sender, 
         MessageInterceptorEventArgs e)
  SmsMessage msg = e.Message as SmsMessage;
  if (msg != null)
    // Process the SMS text message 

Persistent Interceptors

One flaw of solely using the MessageReceived event is that if your application exits you will stop intercepting SMS messages.

If you need to continue to intercept messages while your application is shutdown you need to use a persistent message interceptor.

In order to enable persistent message interception you simply need to call the EnableApplicationLauncher method.

string appId = "ChrisTec-SmsDeviceControl";

The appid parameter is a unique string which uniquely identifies this particular message interceptor. No two message interceptors should use the same value. Common suggestions are to use a randomly generated GUID or a string that contains a company or product specific prefix.

To disable persistent message interception you call a matching DisableApplicationLauncher method.


When an SMS that matches the specified message condition is received by the PDA and the application is not running the OS will automatically restart the application. As part of your application’s startup procedure you need to recreate a new MessageInterceptor instance.

The easiest way to create an instance with an identical configuration is to use an additional constructor overload that reads the values out of the registry location used to store the interceptor details while the application is not running.

if (MessageInterceptor.IsApplicationLauncherEnabled(appId))
  // Persistent message interceptor has been enabled, so
  // pick up the settings from the registry
  interceptor = new MessageInterceptor(appId);
  // A persistent message interceptor is not enabled, so
  // create a new instance and manually setup the
  // interceptor
  interceptor = new MessageInterceptor(...);
  interceptor.MessageCondition = new MessageCondition(...);

As demonstrated in the above code snippet, it is common to see start up code that makes use of the MessageInterceptor.IsApplicationLauncherEnabled method. This method checks if a persistent message interceptor is currently enabled, allowing the application to determine if it needs to register the application launcher or can simply pick up the pre-existing settings.

Sample Application

[Download - 10KB]

A sample application is available for download. The application demonstrates one possible way for a Windows Mobile application to respond to special SMS text messages.

Once the application is ran (and the enabled checkbox is checked) the application will respond to any SMS text message sent to the device that starts with the “CKF:” prefix.

The application parses the contents of the SMS messages it intercepts and interprets them as commands. The following three commands are currently understood:

  • GAME – launches the solitaire game on the PDA
  • HELLO – displays a message box on the PDA’s screen
  • MESSAGE your_message – displays your message on the PDA’s screen

For example an SMS text message containing the text “CKF: MESSAGE Hello World!” would cause the PDA’s screen to display the text “Hello World!”.

If you send an SMS text message with the CKF: prefix that isn’t one of the above commands the application will programatically send an error response message back to the sender.

As SMS text messages are processed you should note that the message counter increases. However if you exit the application and then send an additional text message the counter should restart at 1. This occurs since the counter is not persistent so it does not survive the application re-launch.

Sending SMS messages programatically

Monday, September 15th, 2008

Screenshot of Send SMS applicationWhen developing line of business applications for field service agents it can be handy to have the application send SMS text messages to alert customers of updated status information, such as the potential for the service agent to arrive late for an appointment. This blog post discusses how to send SMS text messages programatically via the .NET Compact Framework.

Supported Platforms

This blog post makes use of classes within the Microsoft.WindowsMobile.PocketOutlook assembly. This assembly is not part of the .NET Compact Framework, instead it is shipped as part of the Windows Mobile operating system.

The assembly was first introduced as part of Windows Mobile 5.0. If you need to send SMS messages from a Windows Mobile 2003 device you will need to utilise a third party component such as the Mobile In The Hand product (which provides a compatible interface) or manually wrap the underlying native APIs.

In order for the demos in this blog post to work you need to add references to the following two assemblies:

If you forget the reference to the Microsoft.WindowsMobile assembly you will get the following compile time error:

The type ‘Microsoft.WindowsMobile.IApplicationLauncher’ is defined in an assembly that is not referenced. You must add a reference to assembly ‘Microsoft.WindowsMobile, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35′.

Creating an SMS Message

To create a new SMS text message you need to create an instance of the SmsMessage class and then set its various properties.

using Microsoft.WindowsMobile.PocketOutlook;
SmsMessage message = new SmsMessage();
message.To.Add(new Recipient("Jane Doe", "+1 45 123456"));
message.Body = "Would you like to go to lunch?";

The Body property is a string which contains the message you want to send. Notice that the To property is a collection of recipients, so a single SMS can be addressed to one or more recipients.

There is even a constructor overload which helps with the common case of a simple message intended for a single recipient:

SmsMessage message = new SmsMessage("+1 45 123456",
  "Would you like to go to lunch?");

Sending an SMS Message

Once we have created the SMS message we need a way to cause it to be sent. There are a couple of ways to achieve this.

The easiest is to call the send method on the SmsMessage instance as shown below:

// Send the SMS to its recipient(s)

Calling the send method sends the SMS message behind the scenes with no visual indication that something is occurring.

Alternatively if you would like to give the user a chance to review and edit the contents of the message before it is sent you can display the message within the built in messaging application via the MessagingApplication.DisplayComposeForm method.

// Display the new SMS in the standard
// messaging application

The third and final way is to create an instance of the OutlookSession class and use it’s SmsAccount property as follows:

using (OutlookSession session = new OutlookSession())

Testing within an Emulator

The Windows Mobile 6 SDK introduced a Cellular Emulator tool which makes it easy to test applications which interact with cellular phone based functionality. One advantage of using this tool to test SMS sending applications is that it avoids the charges typically associated with sending SMS messages via real devices.

You can find the Cellular Emulator within your desktop’s Windows start menu. The first step in using the Cellular Emulator is to connect it to your device emulator. This can be achieved by following the Cellular Emulator Quick Start instructions available on MSDN.

If you need further assistance configuring the Cellular Emulator, Jim Wilson has created a great video titled “How Do I: Configure the Device Emulator to Use an Emulated Cellular Connection?“.

Once correctly configured you can switch to the SMS tab of the Cellular Emulator to send messages to, or view messages received from the device emulator.

Screenshot of SMS tab within the Cellular Emulator application

Demo Application

[Download - 9KB]

A small example application is available for download which demonstrates how to send SMS messages programatically. It displays a simple form to capture the desired message and recipient phone number and then demonstrates a few techniques for sending the message.

Of note is a checkbox which makes the program append onto the end of the user’s message the current battery charge status. This is a lead into the next blog post which will discuss how to programmatically respond to a Windows Mobile device receiving a SMS text message.

30 Days of Windows Mobile – Day 06: Pocket PasswordGen

Thursday, September 11th, 2008

Screenshot of PasswordGen applicationIf you are like me you will have access to a number of password protected online services. Each time I am requested to change my password for one of these services, I struggle to come up with a unique yet strong password.

The following application is designed to make the process of creating new passwords much easier. It allows the user to specify the allowable types of characters in their password and optionally shows the password in a phonetic form to make it easier to remember, or quote over a phone.

Defining a datastructure

The first challenge with this application was to determine how to store the required lookup data. For each character that could be used in the generated password we must be able to determine its equivalent phonetic form. This can be represented by the following data structure:

typedef struct {
  TCHAR character;
  LPCTSTR phonetic;
} PhoneticLetter;

We can construct an array of PhoneticLetter entries for each character category that the user can select to include in the generated password.

// Define a lookup table for lower case letters
static PhoneticLetter gbl_lowerCase[] = {
  { 'a', _T("Alpha") },
  { 'b', _T("Bravo") },
  { 'z', _T("Zulu") }

Helper functions can then be written to randomly select letters from these arrays and to convert between character and phonetic forms.

Generating cryptographic strength numbers

In order to generate unique passwords we need a way to pick a character at random. Using a cryptographic strength random number generator is an ideal technique since any weakness in our random number generation algorithm could be used to exploit the passwords we generate.

By using the Windows Cryptographic APIs we can produce a stream of cryptographic strength random numbers. To do this we need to include the wincrypt.h header file and then call the CryptGenRandom function as shown below:

DWORD dwRandomSeed;
// Acquire the cryptographic context	
if (CryptAcquireContext(&hCrypt, NULL, NULL, PROV_RSA_FULL,
                          CRYPT_VERIFYCONTEXT | CRYPT_SILENT))
  // Generate some random bytes.
  // Second parameter is number of bytes to generate
  // Third parameter is where to store generated bytes
  if (CryptGenRandom(hCrypt,
    // dwRandomSeed contains a random value
  CryptReleaseContext(hCrypt, 0);

CryptGenRandom is designed to generate an arbitrary amount of random data. By passing in a DWORD for the third parameter we’ll get 32bits (4 bytes) worth of random data.

Changing Fonts

By default controls within a dialog will utilise the standard dialog font. From the screenshot above you will notice that the “Password” label is slightly larger and bolder than the other labels.

To change the font used by a specific control we can send it the desired font via a WM_SETFONT window message. The following example uses the CreateFontIndirect function to create a new font and then sends it to the password label control via a WM_SETFONT message.

// Create a new font by filling out a LOGFONT
// structure with the desired style details
// and calling CreateFontIndirect
memset(&lf, 0, sizeof(LOGFONT));
HDC hdc = GetDC(NULL);
lf.lfHeight = -9 * GetDeviceCaps(hdc, LOGPIXELSY) / 72;
ReleaseDC(NULL, hdc);
lf.lfWeight = FW_BOLD;
HFONT hFont = CreateFontIndirect(&lf);
// Pass the font to the control via
// the WM_SETFONT message
SendDlgItemMessage(hDlg, IDC_LABEL_PASSWORD,
  WM_SETFONT, (WPARAM)hFont, 0);

Using Checkboxes

Just like radio buttons, a checkbox is another form of button control. You can send the BM_GETCHECK window message to a checkbox to determine it’s current state as shown below:

HWND hWndCtrl = GetDlgItem(hDlg, IDC_CHECKBOX1);
if (SendMessage(hWndCtrl, BM_GETCHECK, 0, 0) == BST_CHECKED)
   // the checkbox is checked

Interacting with the Clipboard

You might be using your PDA’s webbrowser to create an account for an online service. Rather than manually retyping the newly generated password, it may be easier to copy and paste it between applications.

As discussed in a previous blog post adding a SIPPREF control to a dialog will automatically provide a cut/copy/paste popup menu.

To programatically copy something to the clipboard we need to open the clipboard via a call to the OpenClipboard function.

if (OpenClipboard(NULL))
  ... do something with the clipboard ...

Once the clipboard is opened you then can call functions such as EmptyClipboard or SetClipboardData to alter with the contents of the clipboard buffer.

Sample Application

[Download - 61KB]

The C++ source code and a CAB file for this sample application can be downloaded. If you have any questions about the source code or would like to discuss native Windows Mobile development further please leave a comment on this blog entry.

30 Days of Windows Mobile – Day 05: Mobile Capture

Monday, September 8th, 2008

Screenshot of Mobile Capture applicationAfter a long hiatus I am back into blogging while I convert Chris Craft’s 30 Days of Windows Mobile demo applications into native C.

The next application in the series is a screen capture utility that runs directly on a Windows Mobile based PDA.

It has a ton of features and is ideal for capturing screenshots for user manuals etc. Once the settings have been configured the application will minimise itself and stay out of sight. A sound effect plays when a screenshot is captured and the file can then be found in the root directory of the device.

Creating numeric up-down controls

An up-down control is a pair of arrow buttons that can be associated with an edit control to allow the user to adjust the value without needing to use the keyboard.

To set the allowable range and current value of an up-down control you can send it the UDM_SETRANGE32 and UDM_SETPOS window messages as demonstrated in the following example.

// Set the range of the spinbox to 1 to 60
// and the current value to 10
SendDlgItemMessage(hDlg, IDC_SPIN_DELAYTIMER,  
  UDM_SETRANGE32, 1, 60);
SendDlgItemMessage(hDlg, IDC_SPIN_DELAYTIMER, 

The easiest way to associate an up-down control with an edit control is to place it immediately after the edit control in the dialog tab order and then specify the UDS_AUTOBUDDY and UDS_ALIGNRIGHT window styles. The UDS_ALIGNRIGHT window style means the up-down control will automatically resize and move to sit on the right edge of the edit control. While UDS_AUTOBUDDYINT means changing the up-down control’s value will automatically update the text within the edit control.

Using Radio Buttons

When clicked radio buttons send a standard WM_COMMAND window message just like a regular button. You can also determine a radio button’s current state be sending it the BM_GETCHECK window message as shown below:

if (SendDlgItemMessage(hDlg, IDC_CHECKBOX, BM_GETCHECK, 0, 0)
  // do something if the radio button is checked

To group a number of radio buttons together and make them mutually exclusive, they should be placed consecutively in the dialog’s tab order and then the first one should have the WS_GROUP window style set.

Capturing Hardware Buttons

One mode of this application starts the screen capture process when a specified hardware button is pressed.

To override the default behaviour of a hardware button and use it for an application specific purpose we can make use of the RegisterHotKey function:

// Register the VK_APP1 (typically Contacts)
// button as a hotkey for our dialog.
RegisterHotKey(hDlg, 1234, MOD_WIN, VK_APP1);

You can refer to the Windows Mobile documentation for a list of standard hardware button key codes suitable for registration.

When we are finished with a hardware button and want to return it to its default behaviour we can call the matching UnregisterHotKey function:

UnregisterHotKey(hDlg, 1234);

While the hotkey is registered the dialog will be sent WM_HOTKEY window messages whenever the hardware button is pressed. The unique id value we passed to the RegisterHotKey function is provided to us to help determine which hotkey was pressed in case we register more than one.

  if (wParam == 1234)
    // hotkey button has been pressed

Finding Hardware Buttons

Although we could hardcode the combobox list of available hardware buttons, it is better to query the device for this list, as the number of available buttons can vary between devices.

We can query the HKLM\Software\Microsoft\Shell\Keys registry key to find a list of available hardware buttons.

It is of interest to note that many buttons will be listed twice. Many buttons can have a different behaviour associated with them depending upon if they are held down for a short or long period of time.

Taking a screenshot

Calling the GetDC function and passing in the special HWND_DESKTOP value obtains a device context for the entire screen. A device context is roughly analogous to a managed System.Drawing.Graphics instance.

By using the BitBlt function we can copy the bitmap data associated with a rectangular region of one device context into another.

The CreateCompatibleDC and CreateCompatibleBtmap functions can be utilised to create an offscreen bitmap and associated device context suitable for storing the screenshot.

// Save a rectangular area of the screen
// specified by "pRect" to a file specified by "pszFilename".
void Snapshot(WCHAR *pszFilename, RECT *pRect)
  // Create a new bitmap of the required size and a device
  // context to allow us to draw onto it.
  int width = pRect->right - pRect->left;
  int height = pRect->bottom - pRect->top;
  HDC hdcDest = CreateCompatibleDC(hdcSrc);
  HBITMAP hbmp = CreateCompatibleBitmap(hdcSrc, width, height);
  SelectObject(hdcDest, hbmp);
  // Blit (copy) from the source device context (the screen)
  // to the device context that is associated with our
  // offscreen bitmap buffer.
  BitBlt(hdcDest, 0, 0, width, height,
    hdcSrc, pRect->left, pRect->top, SRCCOPY);
  // Finally save our bitmap to disk
  SaveBitmap(pszFilename, hdcDest, hbmp);
  // Free the resources
  ReleaseDC(HWND_DESKTOP, hdcSrc);

Saving a bitmap to file

As discussed by Chris Tacke there are two types of bitmap objects. Device Dependant Bitmaps (DDBs) and Device Independent Bitmaps (DIBs). A bitmap file is basically the raw pixel data of a DIB written to disk with BITMAPFILEHEADER and BITMAPINFOHEADER headers attached to describe the format of the data.

Within the source code available for download there is a small function called SaveBitmap which accepts an HBITMAP and saves the contents to a file.

Sample Application

[Download - 68KB]

The C++ source code and a CAB file for this sample application can be downloaded. If you have any questions about the source code or would like to discuss native Windows Mobile development further please leave a comment on this blog entry.