May 1st, 2009
To round out my coverage of Input Contexts we need to cover the concept of Input Classes. Put simply an input class is a hint to the Windows Mobile OS as to what kind of information should be entered into a text box (for example an email address, phone number, or person’s name).
Selecting an Input Class for a textbox will change the source of data used for the auto suggestions provided by the OS as the user starts typing. For example in the screenshot above you can see the user is typing in a person’s name yet the operating system is suggesting matching cellphone numbers.
To specify the Input Class for a textbox we can use the native SHSetInputContext API and set the SHIC_FEATURE_CLASS feature. Yesterday’s code sample provided a suitable wrapper around this API for this purpose.
[InputContextSendSMS.zip - 10.8KB]
To demonstrate the use of Input Contexts I decided to make a modified version of the SendSMS application I presented earlier. In this modified version when a user starts to type in a person’s name into the phone number textbox the operating system will provide suggested phone numbers based upon data found within Pocket Outlook’s contacts list.
The code changes required to the original sample application were minimal and consisted of the following two lines of code which use the InputClass developed yesterday.
// Setup the input context for the phone number text box
// so that it will provide auto suggestions of phone numbers
// associated with outlook/SIM contacts.
The call to SetHaveTrailer means that if the user selects a suggestion from the popup list the OS will not automatically insert a seperator character. If you set this feature to true a semicolon would be inserted allowing the user to quickly create a list of two or more recipients.
April 30th, 2009
In my last blog post I discussed how an end user could change word completion features at a system wide level. This blog post covers how a .NET Compact Framework developer can programatically change the behaviour on a textbox by textbox basis.
The Windows Mobile operating system provides a function called SHSetInputContext that enables a developer to configure the various properties of the input context associated with a given control.
By using a DllImport declaration we can gain access to this native function from our C# application as shown below:
private enum SHIC_FEATURE : uint
RESTOREDEFAULT = 0,
AUTOCORRECT = 1,
AUTOSUGGEST = 2,
HAVETRAILER = 3,
CLASS = 4
private static extern int SHSetInputContext(IntPtr hwnd,
[MarshalAs(UnmanagedType.Bool)]ref bool lpValue);
Once declared it is as easy as passing a boolean true or false value to SHSetInputContext along with the name of the input context feature we want to configure.
For example to disable auto suggestion for a textbox called “textbox1″ we could use the following code snippet:
bool value = false;
[Download InputContextDemo.zip - 10.6KB]
A sample application is available for download. It wraps up the calls to SHSetInputContext into a handy InputContext class that can be re-used within your own applications.
The sample application has a single textbox and a series of checkboxes. The checkboxes enable you to control the various input context features present within the Word Completion tab of the Input control panel applet for the textbox.
We’ll round out our discussion of Input Contexts by covering Input Classes within the next blog post. In the mean time see if you can determine what changes in behaviour occur when you select the various options within the Input Class combo box.
April 23rd, 2009
Another Windows Mobile feature that is commonly undiscovered are the word completion settings. You can find these within the “Input” control panel applet, found within the Personal tab of the Settings application.
Although the labeling and precise set of options available changes with Windows Mobile version you should be able to configure the following types of word completion features:
- Suggest words when entering text: Should Windows Mobile suggest possible ways to complete the word currently being entered via a popup list.
- Add a space after word: Should a space be automatically inserted if the user selects a word from the word completion list.
- Enable auto correct: Should common typing mistakes such as typing “youre” when you meant “you’re” be corrected automatically when typing a space after the word.
Enabling the Auto Correct feature is more practical for English speakers than it is for other users of other languages. The rules and auto corrections are rather hardcoded and may interfere with phrases common in other languages. You may spend more time correcting the auto corrections than it spends correcting your mistakes!
Now for the bad news… your mileage may vary with this Windows Mobile Tip. Although the word completion feature is a standard part of the operating system there are a number of “moving parts” between the keyboard and the application which could affect text input behavior. Altering these settings on your particular device may or may not alter the word completion behavior of your device, as word completion may be implemented or controlled by another part of the software stack (for example a custom Software Input Panel developed by the device’s OEM).
Tomorrow we’ll discuss how a .NET Compact Framework developer can programmatically control these word completion features on a textbox by textbox case.
April 22nd, 2009
Here is a handy feature of Visual Studio which took me a while to discover when I started using the tool.
As part of packaging up an application it is common to store configuration settings within the registry. While using a Smart Device CAB project you can use the convenient Registry view to set up these values graphically.
The feature that I didn’t notice for a while is the fact that you can right click on the window to get an Import… menu item (as shown in the screenshot above). This enables you to import a group of settings from a *.reg file, which saves you manually entering them all via the IDE.
So how do you create a *.reg file? One way is to manually write one in a text editor. Another is to generate it via the Windows CE Remote Registry Editor utility. Once you have configured your device you can use this tool to export a specific sub-tree of the device’s registry as a *.reg file that you can then import directly into Visual Studio.
December 15th, 2008
For some Line of Business (LOB) applications intended for tightly controlled deployment environments you may want to programatically set the Device Name of each PDA. This blog post discusses one common technique for achieving this.
Changing the Device Name
A Windows Mobile device stores the Device Name in the registry underneath the HKEY_LOCAL_MACHINE\Ident\Name value. This means we can make use of the Microsoft.Win32.Registry class to change the value and hence update the device name.
A code snippet for achieving this could take the following form.
void SetDeviceName(string deviceName)
// Change the device name of the current Windows Mobile device
using (RegistryKey key = Registry.LocalMachine.OpenSubkey("Ident", true))
Verifying the change
The device’s TCP/IP stack utilises the device name as the device’s hostname. So an easy way to verify that the change has been successfully made is to ask what the current hostname is. This process is demonstrated below.
// Determine the current host name
MessageBox.Show(Dns.GetHostName(), "Current Device Name");
Be aware however that certain parts of the operating system may require additional steps to be taken in order for them to read the updated information stored in the registry. Refer to the article titled “Naming a Device” available on MSDN for additional guidance.
[Download setdevicename.zip - 9.64 KB]
A small sample application is available for download. It demonstrates setting the device name programatically and includes two buttons to enable the user to verify that the change has been correctly made.
The first button asks the DNS subsystem for the current host name, while the second makes use of a technique discussed previously to display the Device ID control panel applet.
Another way to verify the change has been made is to simply connect the PDA to your desktop PC via ActiveSync. The main ActiveSync window displayed on the PC should display the device name in the top left hand corner.