[转]让可编辑控件支持输入法状态自动切换与剪切/复制/粘贴（Windows Mobile）
简单的说就是将WC_SIPPREF（State of Input Panel Control）添加为对话框的最后一个控件。
MSDN上的链接为：http://msdn.microsoft.com/en-us/library/ms914097.aspx
我还惊喜地发现了下面这篇文章，写的非常好，把这个小东西针对各种情况写得很全面，所以特将它转载过来：
原文地址：http://www.christec.co.nz/blog/archives/146
Add Cut/Copy/Paste functionality to a Textbox
Earlier I discussed how you could manually get the software keyboard (SIP) to display whenever a TextBox control gained focus. There was potentially a lot of event handlers to write, two for every control on a form. Today I will show you an alternative approach that utilises less code but also has some additional benefits.
A common thing I do while testing new Windows Mobile applications, is to tap-and-hold on a text field. Very well behaved applications should popup a context sensitive menu containing cut/copy/paste style options for the current control. Surprisingly, very few applications actually pass this test, even though it is a feature that has been built into the operating system for a while.
Within Windows CE the SIPPREF control can be used to automatically implement default input panel behavior for a dialog. It provides the following features:
- The Input Panel is automatically shown/hidden as controls gain and loose focus.
- Edit controls have an automatic context menu with Cut, Copy, Paste type options.
- The SIP state is remembered if the user switches to another application and later returns to this form.
In my mind this has three advantages over the process I previously discussed.
- You add the SIPPREF control once and it automatically hooks up event handlers for each of your controls. With the manual event handler approach it’s easy to add a new control and forget to hook up the events required to handle the SIP.
- You get free localisation. Although you could create a custom context menu for cut/copy/paste, you would need to localise the text into multiple languages yourself (if you are concerned with true internalisation that is) and it’s another thing thing to hook up for each control.
- You get standardised behavior. By using functionality provided by the operating system you are ensuring that your application has a natural and expected behavior to it. If the platform ever changes the conventions of SIP usage, your application will automatically be updated.
For the rest of this blog entry I will discuss how to go about utilising the SIPPREF control within your application. I have split my discussion into two sections. The first section will be of interest to native developers developing in C or C++, while the second section is intended for .NET Compact Framework developers.
Each section contains a small example application which demonstrates the behaviour of the SIPPREF control within the respective environment. When you run the sample applications you will notice that the SIP does not popup up when you click within a text box. And a tap-and-hold operation yields nothing. This behaviour changes when a SIPPREF control is added to the dialog, which can be achieved by clicking the sole button.
Native Developers
In order to use the SIPPREF control we must first request the operating system to register the SIPPREF window class. We do this by calling the SHInitExtraControls function. This step only needs to be done once, so is typically done during your application’s start up code. It is very easy to call, as the following example demonstrates:
#include <aygshell.h> SHInitExtraControls();
Since SHInitExtraControls lives within aygshell.dll, we also need to modify our project settings to link with aygshell.lib, otherwise the linker will complain that it can not find the SHInitExtraControls function.
Once we have registered the SIPPREF window class, we simply create a SIPPREF control as a child of our dialog. When the SIPPREF control is created it will enumerate all sibling controls and subclass them in order to provide the default SIP handling behaviour. The SIPPREF control must be the last control added to your dialog, as any controls added after the SIPPREF control will not be present when the SIPPREF control enumerates its siblings, and hence will not be subclassed to provide the proper SIP handling.
If dynamically creating the SIPPREF control, a good place to do this is within the WM_CREATE or WM_INITDIALOG message handler, as the following code sample demonstrates:
case WM_INITDIALOG:
// Create a SIPPREF control to handle the SIP. This
// assumes 'hDlg' is the HWND of the dialog.
CreateWindow(WC_SIPPREF, L"", WS_CHILD,
0, 0, 0, 0, hDlg, NULL, NULL, NULL);
As an alternative to dynamically creating the SIPPREF control, we can place the control within our dialog resource by adding the following control definition to the end of a dialog within the project’s *.rc file.
CONTROL "",-1,WC_SIPPREF, NOT WS_VISIBLE,-10,-10,5,5
Depending upon your developer environment you may even be able to do this entirely from within the Resource Editor GUI. For example within Visual Studio 2005 you could drag the “State of Input Panel Control” from the Toolbox onto your form to cause a SIPPREF control to be added.
.NET Compact Framework Developers
The process of using the SIPPREF control for a .NET Compact Framework application is fairly similar to that of a Native application. Since the .NET Compact Framework does not natively support the use of dialog templates, we must use the CreateWindow approach to create a SIPPREF control dynamically at runtime.
The first step is to declare a number of PInvoke method declarations for the various operating system APIs we need to call.
using System.Runtime.InteropServices; [DllImport("aygshell.dll")]
private static extern int SHInitExtraControls(); [DllImport("coredll.dll")]
private static extern IntPtr CreateWindowEx(
uint dwExStyle,
string lpClassName,
string lpWindowName,
uint dwStyle,
int x,
int y,
int nWidth,
int nHeight,
IntPtr hWndParent,
IntPtr hMenu,
IntPtr hInstance,
IntPtr lpParam); private static readonly string WC_SIPPREF = "SIPPREF";
private static readonly uint WS_CHILD = 0x40000000;
One interesting fact is that we PInvoke a function called CreateWindowEx, while the native example above called CreateWindow. If you dig deeper into the Window Header files you will notice that CreateWindow is actually a macro which expands into a call to CreateWindowEx. At the operating system level the CreateWindow function doesn’t actually exist.
With this boiler plate code out of the way, the solution is very similar to the native one…
protected override void OnLoad()
{
// Initialise the extra controls library
SHInitExtraControls(); // Create our SIPPREF control which will enumerate all existing
// controls created by the InitializeControl() call.
IntPtr hWnd = CreateWindowEx(0, WC_SIPPREF, "", WS_CHILD,
0, 0, 0, 0, this.Handle, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero);
}
In the above example we simply create the SIPPREF control within the OnLoad method of our form. Within the downloadable sample project I have wrapped up this code into a static method called SIPPref.Enable(Form f) to enable to it easily be reused between forms.
Hopefully today I have shown you that having knowledge of the underlying operating system is still a useful skill to have for .NET Compact Framework developers. Knowing the features provided by the operating system can allow you to add some neat functionality to your applications with little additional effort on your behave.
