System and method for automatically switching between writing and text input modes

Abstract

A method and system for automatically determining when an application should switch from a writing mode to a text entry mode, and vice-versa. When a soft input panel (SIP) or input method (IM) is selected, the application is notified and enters a text entry mode. Inputting via the IM while in this mode causes a character to be sent to the application, while pen events in the application window enable text editing and the selection of text and ink data in the application widow. When the SIP is deselected, the application is notified and enters a pen (writing) mode, whereby the pen events are interpreted as digital ink strokes instead of characters. Sub-modes of the pen mode are also available, via which the pen events are used to manipulate existing ink in the application window. Visual feedback may be provided to remind the user of the current mode and/or sub-mode.

Claims

What is claimed is:

1. In a computer system, a method comprising:

receiving a request to select an input panel, the request received external to an executing application program;

selecting the input panel, including displaying a representation thereof;

notifying the executing application program that the input panel was selected, and in response, the application program enabling a text entry mode and having at least a first displayed area corresponding to the application program that is visible while the representation of the input panel is displayed;

receiving input data in the input panel, passing the input data to an input method, receiving text from the input method, and passing the text to the application program; and

receiving input data comprising pen events directed to the first displayed area, passing the input data to the application program, the application program handling the pen events as text editing commands while the application program has the text entry mode enabled.

2. The method of claim 1 wherein the application program further disables a digital ink mode in conjunction with enabling the text entry mode.

3. The method of claim 1 further comprising displaying visual feedback indicative of the text entry mode including resizing a text display window of the application program.

4. The method of claim 3 wherein the representation of the input panel is displayed in the application program based on the resizing of the text display window.

5. The method of claim 1 further comprising displaying visual feedback indicative of the text entry mode including removing horizontal lines from a window of the application program.

6. The method of claim 1 wherein enabling a text entry mode comprises setting a caret in the first area corresponding to the application program.

7. The method of claim 1 further comprising applying the text editing commands at the application program to edit text displayed in the first area.

8. The method of claim 7 wherein applying the text editing commands includes setting a caret position.

9. The method of claim 7 wherein applying the text editing commands includes selecting at least some text displayed in the first area.

10. The method of claim 1 further comprising, receiving a further request to deselect the input panel, disabling the text entry mode in response to the request, including removing the displayed input panel, enabling a pen mode in response to the request, receiving input as pen events directed to the application program, and interpreting at least some of the pen events as digital ink in the application program.

11. The method of claim 10 further comprising, displaying visual feedback indicative of the pen mode, including resizing a window of the application program based on removing the displayed input panel.

12. The method of claim 10 further comprising, displaying visual feedback indicative of the pen mode, including drawing horizontal lines in a window of the application program.

13. The method of claim 10, wherein interpreting at least some of the pen events as digital ink comprises storing digital ink based on the pen events.

14. The method of claim 10 further comprising, interpreting at least some of the pen events based on the state of at least one sub-mode.

15. The method of claim 14 wherein a sub-mode comprises a select sub-mode in an enabled state, and wherein interpreting at least some of the pen events based on the state of at least one sub-mode comprises selecting an area of a window of the program.

16. The method of claim 15 wherein interpreting at least some of the pen events based on the state of at least one sub-mode comprises performing an action on digital ink displayed in the selected area.

17. The method of claim 14 wherein a sub-mode comprises an insert space sub-mode in an enabled state, and wherein interpreting at least some of the pen events based on the state of at least one sub-mode comprises inserting space in a window of the program.

18. A computer-readable medium having computer-executable instructions for performing the method of claim 1.

19. In a computer system, a system for providing data to a program, comprising:

an input panel having a selected state and a deselected state;

an input method corresponding to the input panel;

an input mechanism that receives input data;

an operating system connected to an input panel manager to determine the state of the input panel and, when selected, to further determine whether received input data was directed to the input panel, the operating system and input panel manager further configured to:

1) pass the received input data to the input method when the input panel is in the selected state and the input data is directed to the input panel, receive text from the input method, and pass the text to the program;

2) pass the received input data to the program when the input panel is in the selected state and the input data is directed to an input display area of the program and not directed to the input panel, the program interpreting the input data as text editing commands for editing text; and

3) pass the received input data to the program when the input panel is in the deselected state and the input data is directed to the program, the program interpreting at least some of the input data as digital ink data.

20. The system of claim 19 further comprising, displaying visual feedback indicative of when the input panel is in the selected state with respect to the deselected state.

21. The system of claim 19 wherein displaying visual feedback indicative of when the input panel is in the selected state includes removing horizontal lines from a window of the application program.

22. The system of claim 19 wherein the input panel is in the selected state, and wherein received input data that is not directed to the input panel is passed to the program and is interpreted by the program as the text editing data to edit displayed text.

23. The system of claim 19 wherein the text editing data is interpreted to select at least some of the displayed text.

24. The system of claim 19 wherein the input panel is in the deselected state, and wherein at least some of the input data passed to the program is interpreted by the program as data for editing digital ink.

25. A computer-readable medium having computer-executable components that implement the system of claim 19.

26. In a computer system, a method for providing data to a program, comprising the steps of:

(a) providing an input panel having a selected state and a deselected state;

(b) receiving input data;

(c) if the input panel is in the selected state and the input data is directed to the input panel,

(1) passing the input data to an input method,

(2) receiving text from the input method, and

(3) passing the text to the program as received data;

(d) if the input panel is in the deselected state, passing the input data to the program as the received data such that the program interprets the received data in a pen mode, and

(e) if the input panel is in the selected state and the user input data is directed to a visible text display area corresponding to the program and not to the input panel, passing the input data to the program as the received data such that the program interprets the received data in a text editing mode.

27. The method of claim 26, wherein the input panel is a separate program selected and deselected external to the program, and further comprising, notifying the program when the input panel is selected, and notifying the program when the input panel is deselected.

28. A computer-readable medium having computer-executable instructions for performing the method of claim 26.

29. A computer implemented method, comprising:

displaying a representation of an input panel when in a selected state;

receiving a first request to change the selected state of the input panel to a deselected state;

removing the representation of the input panel when in the deselected state;

notifying a program of the first request, and in response, the program enabling a digital ink entry mode without requiring further manual input directed to a mode change, and providing visual feedback indicative of the digital ink entry mode;

receiving a second request to change the deselected state of the input panel to the selected state;

notifying a program of the second request, and in response, the program enabling a text entry mode in which at least some input data events received outside the input panel and in a visible area that displays entered text are passed to the program and interpreted by the program as text editing events.

30. The method of claim 29 wherein the text entry mode is enabled, and wherein at least some input data events received in an area corresponding to the displayed input panel are converted to text and passed to the program.

31. A computer-readable medium having computer-executable instructions for performing the method of claim 29.

Description

TECHNICAL FIELD

The invention relates generally to computer systems, and more particularly to the input of data into a computer system.

BACKGROUND OF THE INVENTION

Small, mobile computing devices, including hand-held and palm-size computers and the like, are becoming important and popular user tools. In general, they are becoming small enough to be extremely convenient while consuming less and less battery power, and at the same time becoming capable of running more powerful applications.

Although such devices continue to shrink in size, size limitations are being reached as a result of human limitations. For example, a full character keyboard that enables user data input cannot be so small that human fingers cannot depress the individual keys thereon. As a result, such devices (e.g., palm-size computers) may eliminate the full size physical keyboard and provide a representation of a keyboard on a touch-sensitive display. To this end, the user enters characters by touching the screen with a stylus at locations corresponding to the displayed keys. Of course, touch-screen devices can also be used simultaneously with devices having physical keyboards, whereby characters can also be entered by manually pressing the keys of the physical keyboard.

Alternatively, the user may wish to input handwritten notes such as sketches and other writing to the device. Applications are known that receive pen movements as digital ink, and the ink is displayed as it is input. The application may store the digitized ink as is, or the application may interpret some of the ink, e.g., it may attempt character recognition, and then store the interpretation as ASCII text or the like.

One of the difficulties in working with such applications is that the user may wish to enter text (e.g., by tapping a keyboard) at certain times, and write digitally (by dragging the pen) at other times. Contemporary devices presently force the user to manually switch between a distinct text entry and a drawing application, or mode, with no intuitive mixing of text and graphics. Moreover, while in each application or mode, the same type of pen stroke may be interpreted different ways. For example, if the user is in a writing application, the dragging of the pen may be used at one time to input ink, and at another time to select a section such as for cutting or pasting purposes. In a text application, the dragging of the pen may select text. In sum, contemporary application and/or mode switching is neither convenient nor intuitive to users, yet heretofore was needed to inform the system of the user's intentions so as to handle pen events in the manner desired by the user.

SUMMARY OF THE INVENTION

Briefly, the present invention provides a method and system for modifying the computer system to receive text input or writing (pen or ink) input based upon the selected or deselected state of an input panel selected by the user. When the system receives a user request to select an input panel, a text entry mode of an application program is enabled in response to the request, including displaying visual feedback indicative of the text entry mode. As data input such as in the form of user pen events are received on the input panel, the pen events are passed to an input method corresponding to the input panel, which converts the user pen events into text. The text is then passed as input data to a program. While in the text entry mode, pen events received in the program's window are passed to the program to enable editing.

When a request to deselect the input panel is received, the text input state is automatically disabled, including displaying visual feedback indicative of the disabled text input state, and a writing input mode is automatically enabled in the application program. The writing input mode includes displaying visual feedback to the user indicative of the writing input state. When user pen events are received, the pen events are passed as input data to the program. The program interprets the pen events as digital ink, or, if in a user-selected sub-mode of the writing/pen mode, interprets the pen events as an ink editing operation.

Thus, the switching of modes is automatic based on the state of an input panel, which is intuitively selected by the user. Visual feedback may also be provided to remind the user of the current mode. The state of the input panel determines how pen events will be handled, in that if the input panel is in a non-selected state, the pen events are passed as input data to the program. If the input panel is in a selected state, the pen events are passed to an input method of the input panel window, resulting in text being received from the input method. The text is then passed as input data to the program.

Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram representing a computer system into which the present invention may be incorporated;

FIG. 2 is a block diagram representing an underlying system architecture into which the present invention may be incorporated;

FIG. 3 is a flow diagram generally representing a process for getting user input from an input method to a selected application;

FIG. 4 is a state diagram generally representing SIP selection states;

FIG. 5 represents a display on a touch-sensitive display screen on an exemplary computing device showing an application for handling both text and ink input;

FIG. 6 represents a display on a touch-sensitive display screen showing the application of FIG. 5 wherein the text entry mode has been entered via selection of a Soft Input Panel (SIP);

FIGS. 7 and 8 represent a display on a touch-sensitive display screen showing text editing operations while in the text entry mode;

FIG. 9 represents a display on a touch-sensitive display screen showing the application of FIG. 5 wherein the writing/pen mode has been entered via de-selection of the SIP;

FIGS. 10-16 represent a display on a touch-sensitive display screen showing various exemplary writing (inking) and ink editing operations while in the writing/pen mode;

FIG. 17 is a flow diagram representing general steps taken to switch to the text entry mode in accordance with an aspect of the present invention;

FIG. 18 is a flow diagram representing the detection and handling of pen events while in the text entry mode in accordance with an aspect of the present invention;

FIG. 19 is a flow diagram representing the handling of pen events detected in the application window to select and edit while in the text entry mode;

FIG. 20 is a flow diagram representing general steps taken to switch to the pen mode in accordance with an aspect of the present invention;

FIG. 21 is a flow diagram representing the detection and handling of pen events while in the pen mode in accordance with an aspect of the present invention; and

FIG. 22 is a flow diagram representing the handling of pen events detected in the application window while in the pen mode.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Exemplary Operating Environment

FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a hand-held computing device such as a mobile device. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types.

Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including palm-sized, desktop or laptop personal computers, mobile devices such as pagers and telephones, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a hand-held personal computing device 20 or the like, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system 26 (BIOS), containing the basic routines that help to transfer information between elements within the hand-held computer 20, such as during start-up, is stored in the ROM 24.

A number of program modules are stored in the ROM 24 and/or RAM 25, including an operating system 28 (preferably Microsoft Corporation's Windows.RTM. CE operating system), one or more application programs 29, other program modules 30 and program data 31. A user may enter commands and information into the hand-held computer 20 through input devices such as a touch-sensitive display screen 32 with suitable input detection circuitry 33. Other input devices may include a microphone 34 connected through a suitable audio interface 35 and a physical (hardware) keyboard 36 (FIG. 2). The output circuitry of the touch-sensitive display 32 is also connected to the system bus 23 via video driving circuitry 37. In addition to the display 32, the device may include other peripheral output devices, such as at least one speaker 38 and printers (not shown).

Other external input or output devices 39 such as a joystick, game pad, satellite dish, scanner or the like may be connected to the processing unit 21 through an RS-232 or the like serial port 40 and serial port interface 41 that is coupled to the system bus 23, but may be connected by other interfaces, such as a parallel port, game port or universal serial bus (USB). The hand-held device 20 may further include or be capable of connecting to a flash card memory (not shown) through an appropriate connection port (e.g., slot) 42 and interface 43. A number of hardware buttons 44 such as switches, buttons (e.g., for switching application) and the like may be further provided to facilitate user operation of the device 20, and are also connected to the system via a suitable interface 45. An infrared port 46 and corresponding interface/driver 47 are provided to facilitate communication with other peripheral devices, including other computers, printers, and so on (not shown). It will be appreciated that the various components and connections shown are exemplary and other components and means of establishing communications links may be used.

Soft Input Panel

The soft input panel architecture is primarily designed to enable the input of text such as character, key-based and other user data via the touch screen 32 of the device 20 rather than a physical keyboard 36. However, as can be appreciated, a given computer system 20 may optionally and additionally include a physical keyboard, as represented by the dashed box 36 of FIG. 2. Moreover, as will become apparent, the "soft input panel" need not be an actual touch-sensitive panel arranged for directly receiving input, but may alternatively operate via another input device such as the microphone 34. For example, spoken words may be received at the microphone 34, recognized, and displayed as text in an on-screen window, e.g., a soft input panel.

FIG. 2 shows a block diagram implementing the SIP architecture. The computer system 20 includes an operating system 28 such as the graphical windowing environment 60. Such a graphical windowing environment 60 is generally operational to receive user input through a variety of devices including the keyboard 36, a mouse (not shown), a digitizer (not shown) and so on. In turn, the graphical windowing environment 60 may provide such user input to an application having "input focus," frequently in the form of a keyboard character event. Note that a number of applications 29 may be executable by the computer system, however one application that is currently running is said to have "input focus" and receive the input.

The preferred architecture employs a SIP manager 58 to provide a single and flexible interface for a plurality of different input methods 64. In general, the SIP manager 58 provides text in the form of encoded keystrokes from a selected input method 64 to the graphical windowing environment 60 (e.g., the Windows CE operating system 28). Once received, the graphical windowing environment 60 sends information corresponding to the user input data to an application 29 (i.e., the application whose window currently has input focus) in the form of that keystroke, mouse or other message placed in the message queue of the application's window. The passing of such messages is well known in Windows programming and is described in "Programming Windows 95," Charles Petzold, Microsoft Press (1996), hereby incorporated by reference. As a result, any application capable of handling text input (e.g., in the form of ASCII or Unicode characters) may be used with any appropriately-configured input method 64. Indeed, if an optional keyboard 36 is present, keystrokes are directly provided by a keyboard driver 62 to the graphical windowing environment 60, whereby appropriate keystrokes are likewise placed in the message queue of the active application's window without the application being provided with information as to the source.

Input methods 64 may include, for example, various different displayable keyboards, (soft keyboards), a calculator, a formula and/or equation editor, chemical symbol template, voice recognition, handwriting recognition, shorthand symbol recognition, or other application-optimized input methods (e.g. a barcode reader). The SIP manager 58 provides a user interface for permitting a user to toggle a SIP window (panel) 50 (FIG. 7) between a selected (opened) and deselected (closed) state, as described in more detail below. The SIP manager 58 also provides a user interface enabling user selection from a displayable list of available input methods. A user interacting with the user interface may select an input method 64, and in response, the SIP manager 58 loads and calls the selected input method 64. In a preferred embodiment, each of the input methods communicates with the SIP manager 58 through a COM (Component Object Model) interface shown as IIMCallback 61 and IInputmethod 63. A COM object comprises a data structure having encapsulated methods and data that are accessible through specifically defined interfaces. A detailed description of COM objects is provided in the reference entitled "Inside OLE," second edition, Kraig Brockschmidt (Microsoft Press), hereby incorporated by reference.

Generally, when the SIP window 50 is toggled between the selected and deselected states, as will be described in more detail below, the SIP manager 58 informs the selected input method 64 to correspondingly open/close the SIP window 50 through the IInputmethod mechanism 63. When a new input method is selected, the SIP manager 58, through the mechanism 63, informs any of the previously selected input methods to exit, and loads the newly selected input method. The interface 63 may also be utilized by the SIP manager 58 to obtain information specific to a selected input method, as also described in detail below.

The selected input method 64 may also communicate information to the SIP manager 58 via the IIMCallback mechanism 61, such as which character or characters were entered by a user, irrespective of whether the character or characters are generated through keyboard selection, handwriting recognition, voice recognition, a formula editor, calculator or the like. Such text input is generally passed to the SIP manager 58, preferably received as (or converted to) a Unicode character (for Windows CE) by the SIP manager 58 and output to the graphical windowing environment 60. Command key information, such as "Ctrl" on a keyboard, may also be provided by the input method 64 to the SIP manager 58 via interface 61.

SIP and input method-specific information may also be communicated through the SIP manager 58, and ultimately to the focused application 29, when the application is optimized for operating with a SIP (i.e., is "SIP-aware") as described in more detail below.

The system operates as generally represented in the steps of FIG. 3. Once an application is selected and has focus (steps 300-302), an input method 64 is selected therefor at step 304. Note that the input method 64 may be selected by the user, or a default input method may be selected for use with a particular application. Additionally, the input method 64 may be one that remains after having been selected for a previous application, i.e., a particular input method stays the same as the user switches between various applications. It is also possible to deselect all input methods, whereby the input data may be sent to an application program 29 without conversion to text. However, if any input method 64 is selected, the SIP window 50 is displayed.

As the user inputs data at step 306, appropriate data is passed to the SIP manager 58 via the IIMCallback mechanism 61, described below. Note that the input method 64 ordinarily first processes the received data at step 306 and converts the data to text. By way of example, one particular input method 64 may convert barcode symbols to Unicode characters representing digits, another input method may convert mathematical entries into a Unicode result (e.g., an entry of `3+6=` sends a `9` to the SIP manager 58), while yet another may be an equation editor (e.g., the characters "Sqrt" are converted into a single Unicode value representing a square root symbol). In a typical example, a keyboard-type input mechanism converts user input data received as screen coordinates to a Unicode character that corresponds to the location that the displayed keyboard was contacted. After any such processing, the input method 64 passes the text/character to the SIP manager 58, which in turn passes those digits to the graphical windowing environment 60 (step 308). At step 310, the application 29 receives the character data from the graphical windowing environment 60 as if the user had entered those digits on a physical keyboard, regardless of the input method used.

As shown in FIGS. 5-7, the soft input panel (SIP) functionality of the system collectively includes a selectable window 50 (FIG. 7), a visible SIP button 52, and various methods and functions (described below). As shown in FIG. 7, the SIP window 50 is a rectangular area provided by the input method 64 that can be deselected and hidden, or selected and shown, at the user's (or an application program's) request. The visible SIP button 52 is located on a taskbar 56 or the like, and provides a touch-sensitive interface by which the user selects or deselects the SIP window 50. Thus, as represented in the state diagram of FIG. 4, the window 50 toggles between an open, visible state (FIG. 7) and a closed, hidden state (FIG. 5) as the user taps the SIP button 52. A present design implements a SIP window 50 that is fixed (docked) on the display 32 at a position just above the taskbar 56. As will become apparent below, the soft input panel design supports other SIP window 50 sizes or positions.

To this end, the operating system 28 creates a dedicated thread (the SIP manager 58) that registers itself as a SIP thread with the Windows CE system. The thread creates the SIP window 50, performs other SIP initialization, and then enters a message loop to respond to messages and user interface activity in the SIP window 50. The thread also serves to dispatch messages to an Input Method's window, and calls into the Input Method 64 to permit the Input Method 64 to create windows that will respond as special SIP windows.

The SIP manager thread 58 is given special status by the system. For example, windows created by the SIP manager 58 thread are topmost windows, and ordinarily will not be obscured by other windows, except, e.g., when the taskbar 56 is activated in an auto-hide mode while the SIP window 50 is displayed. In this case, the SIP window 50 remains displayed in its current location and the taskbar 56 is displayed on top of the SIP window 50. More generally, any user interface element for controlling the SIP may (and should) be placed on top of (rather than underneath) the SIP window 50, whenever the controlling user interface element and the SIP window 50 overlap.

Moreover, when tapped on, the SIP window 50 (and any child windows thereof such as pushbuttons, text entry fields, scrollbars and the like) will not receive the input focus as would conventional program windows. In this manner, the user may interact with the SIP window 50 without changing the system focus. As can be appreciated, changing the system focus each time the user inputs data into the SIP window 50 would be undesirable. The SIP button 52 will also not cause a change of focus for the same reason, i.e., it is undesirable to cause the window with focus to lose focus by tapping on the SIP button 52 to bring out the SIP window 50.

The SIP system enables the selective installation of a specified Input Method 64. As generally described above, each Input Method 64 is an interchangeable component by which the user provides character, text or other user data via the touch-screen display (or some other input device). More particularly, the SIP manager 58 preferably exposes a COM interface that enables the selective installation of Input Methods 64. The Input Method 64 occupies space inside a SIP window 50 created by the system.

Preferably, the Input Method 64 comprises a Component Object Model (COM) object that implements the IInputMethod interface. Notwithstanding, the Input Method 64 and SIP manager 58 can comprise virtually any components capable of communicating with one other through some mechanism, such as by receiving, responding to, and making function calls.

The Input Method 64 is responsible for drawing in the SIP window 50 and responding to user input in the SIP window 50. Typically, the Input Method 64 will respond to user input and convert that input into text which is then sent to the SIP manager 58 via exposed SIP functions. By way of example, one Input Method 64 includes a default QWERTY (alpha) keyboard 66 shown in FIG. 7. More particularly, this Input Method 64 displays an image of the keyboard 66 on the screen 32, and converts taps on that keyboard 66 (detected as screen coordinates) into Unicode characters which are sent to the SIP manager 58 and thereby to the system. Input Methods may be written by application vendors, and are added to the system using COM component installation procedures.

The user interacts with the Input Method 64 manifested in the visible SIP window 50 to create system input. As represented by the state diagram of FIG. 4 and as shown in FIG. 6, the user can select a different Input Method by tapping a SIP menu button 70 on the taskbar 56 that provides a pop-up list (not shown) of available input methods. The user can also select among available Input Methods via a control panel applet (not shown) or the like. The SIP control panel applets communicate with the operating system 28 using the registry and the exposed SIP-aware functionality described below.

As will be described in detail below, the various components cooperate to expose functions, structures, and window messages that enable system applications 29 to respond to changes in the SIP state. An application 29 that uses this functionality to adjust itself appropriately to SIP changes is considered "SIP-aware." Other applications may be SIP-aware yet choose to retain their original size (and thus be partially obscured by the SIP window 50) when appropriate. Moreover, and as also described below, there are exposed functions that enable applications to programmatically alter the SIP state.

Notwithstanding, applications 29 need not be aware of the SIP system in order to benefit from the present invention. Indeed, applications do not ordinarily recognize whether data received thereby originated at a hardware input device such as the keyboard 36 or via user activity (e.g., contact or proximity detected by the screen 32 and detection circuitry 33) within the soft input panel window 50. This enables applications to operate with virtually any appropriate input method, irrespective of whether that application is SIP-aware.

Turning to an explanation of the mechanism that facilitates the operation of an Input Method 64 installed by the SIP manager 58, a SIP-aware application 29 is notified when the SIP window 50 changes state and what the new, current state of the SIP window 50 is. The state includes whether the status of the SIP window 50 is visible or hidden, whether the SIP window 50 is docked or in a floating condition, and the size and position of the SIP window 50. As shown in the table below, a data structure (SIPINFO) contains this SIP information:

                     Typedef struct {
                             DWORD cbSize
                       DWORD     fdwFlags
                       RECT      rcVisibleDesktop
                       RECT      rcSipRect
                       DWORD     dwImDataSize
                       Void  *pvImData
                    } SIPINFO;

                      SHSipInfo (
                                UINT uiAction
                         UINT  uiParam
                         PVOID   pvParam
                         UINT  fwinIni
                      ) ;

          Interface IinputMethod : Iunknown
    {
               HRESULT Select( [in] HWND hwndSip );
        HRESULT Deselect( void );
        HRESULT Showing ( void );
        HRESULT Hiding ( void );
        HRESULT GetInfo ( [out] IMINFO *pimi );
        HRESULT ReceiveSipInfo ( [in] SIPINFO *psi );
        HRESULT RegisterCallback ( [in] IIMCallback* pIMCallback );
        HRESULT GetImData ( [in] DWORD dwSize, [out]
        LPVOID pvImData );
        HRESULT SetImData ( [in] DWORD dwSize, [in]
        LPVOID pvImData );
        HRESULT UserOptionsDlg ( [in] HWND hwndParent );
             }

                        Typedef struct {
                             DWORD cbSize;
                      HIMAGELIST hImageNarrow;
                      HIMAGELIST hImageWide;
                      Int iNarrow;
                      Int iWide;
                      DWORD fdwFlags;
                      Rect rcSipRect;
                             } IMINFO;

                    Interface IIMCallback :
                    Iunknown
                    {
                             Hresult SetImInfo (
                                      IMINFO *pimi );
                                   Hresult SendVirtualKey (
                                            BYTE bVk,
                           DWORD dwFlags );
                                   Hresult SendCharEvents (
                                            UINT uVk,
                           UINT uKeyFlags,
                           UINT uChars,
                           UINT *puShift,
                           UINT *puChars );
                                   Hresult SendString (
                                            BSTR ptrzStr,
                           DWORD dwChars );
                                               }

• Inventors
  Lui, Charlton E.; Parker, Kathryn L.; Altman, Dan W.;
• Assignee
  Microsoft Corporation (Redmond, WA)
• Published
  Dec-21-2004
• Current US Classes:
  345/173
  345/864
  715/531
• Application #
  420301
• International Classes
  G09G 005/00
• Field of Search
  345/168 345/173 345/179 345/771 345/773 345/864 345/866 715/531 341/22
• Examiner
  Eisen; Alexander
• Agent
  Law Offices of Albert S. Michalik, PLLC
• US Patent References:
  5459796
  6034685
  6295372