Ch06_Mouse and Keyboard Input.pdf

(116 KB) Pobierz
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Chapter 6
Mouse and Keyboard Input
This chapter covers mouse and keyboard input, or the smart device equivalent. Mouse and
keyboard are standard input devices on a desktop PC system, but no standard exists for smart
device input. There is, instead, a wide range of available input hardware, limited only by the
imaginations of the platform development teams. Programmers who are new to smart device
programming need to adopt new approaches to thinking about user input when developing
software for smart devices. [Comment 6.1]
Author's Note: In this review chapter C#-Specific Text is highlighted in YELLOW.
Programming for Mouse Input ....................................................................................................... 17
Mouse Events ................................................................................................................... 17
Automatic Mouse Capture ................................................................................... 17
Mouse Event Handlers ........................................................................................ 18
Sample: DrawRectangles ................................................................................................. 20
Drawing stretchable rubber rectangles ............................................................... 20
Collecting the points ............................................................................................ 23
Drawing the rectangles........................................................................................ 25
Mouse debugging tips ......................................................................................... 26
About Paint Events .............................................................................................. 27
Setting the Mouse Cursor................................................................................................. 28
The Pocket PC 2002 emulator support for mouse input and cursors ................. 29
Setting the Mouse Cursor using Win32 functions ............................................................ 30
Programming for Keyboard Input ..................................................................................................31
Sources of Keyboard Input ............................................................................................... 32
Device Buttons .................................................................................................... 32
Software Input Panel (SIP) .................................................................................. 32
A Keyboard .......................................................................................................... 34
The Win32 keybd_event function..................................................................... 34
The Unicode Character Set................................................................................. 34
Keyboard Events .............................................................................................................. 35
Focus events ....................................................................................................... 35
Activation events ................................................................................................. 36
Chapter 6 – Mouse and Keyboard Input
Page 1
Copyright © 2002 Paul Yao & David Durant
 
Programming the .NET Compact Framework in VB
By Paul Yao & David Durant
For Desktop .NET Framework Programmers...................................................... 37
Keyboard Event Sequences................................................................................ 37
Device buttons in the Pocket PC 2002 emulator................................................. 39
Keyboard Event Handlers ................................................................................... 40
Sample: KeyInput ............................................................................................................. 41
Responding to SIP changes using the InputPanel control.................................. 42
Subclassing versus event handlers..................................................................... 43
Subclassing a TextBox ........................................................................................ 43
Subclassing and the Windows Forms Designer ................................................. 44
Identifying methods which you can override ....................................................... 45
Sample: KeyState ............................................................................................................. 48
Sample: Caret...................................................................................................................50
Creating and destroying a caret .......................................................................... 52
Moving a caret ..................................................................................................... 53
Sample: Sleep .................................................................................................................. 54
Pushing the power button.................................................................................... 55
Reading and writing system time-out values....................................................... 55
Conclusion ..................................................................................................................................... 56
Some smart devices have a mouse – or an equivalent, like the touch screen on the Pocket PC.
Other devices have no pointing device, like the SmartPhone, which has neither mouse nor touch
screen. The differences between the hardware of these two devices obviously mean that the type
of input you can expect to receive on each of these two devices is different. [Comment 6.2]
Some smart devices have a keyboard – or equivalent. Some custom CE devices, for example,
have a complete alphanumeric keyboard. Pocket PCs do not have a hardware keyboard, but the
onscreen Software Input Panel (SIP) allows input of character data 1 . The keyboard on a
SmartPhone has a phone keypad plus a few command input keys. As these examples show, there
is much variation in the available methods for getting character data. [Comment 6.3]
We use the terms mouse and keyboard in this chapter to refer to any input device that provides
the same type of input – pointing or character key input – as a desktop device. Because the
landscape of input devices for Windows CE is different from the desktop, programmers new to
smart device programming need to adopt new approaches to thinking about user input that is
appropriate to the new breed of smart devices. [Comment 6.4]
Overview of Input
Most Windows CE devices do not have the same input hardware that you find on desktop
PCs. Consider a Pocket PC, which has a touch-sensitive screen for pointing, and an on-screen
Software Input Panel (which has a keyboard as one of several supported input methods) for
character input. Some Pocket PCs have navigation keys, the equivalent of arrow keys (up, down,
left, and right) found on desktop systems. [Comment 6.5]
These are big differences, which you ought to take into account in the design of your
software. Otherwise, your software may fall short of your users' expectations, which may cause
them to avoid using your software. To satisfy user expectations, you must learn about their
expectations, which are often based on their experience using other software running on a
particular smart device. [Comment 6.6]
1 There are external keyboards that you can connect to various Pocket PCs, some from the
device manufacturer and others from third parties. We wrote some of the text for this book, in
fact, using one external keyboard with a Pocket PC.
Chapter 6 – Mouse and Keyboard Input
Page 2
Copyright © 2002 Paul Yao & David Durant
870585272.016.png
 
Programming the .NET Compact Framework in VB
By Paul Yao & David Durant
One way to understand your users is to become a user of the smart device you are targeting 2 .
For example, if you plan to write software for a Pocket PC, you ought to acquire a Pocket PC and
use it on a regular basis. If you are planning to write software for a SmartPhone, it is not enough
that you have experience with other mobile phones. You must spend time using this particular
breed of mobile phone to understand what users expect to find in the user-interface, and how they
expect to navigate the user-interface. [Comment 6.7]
Nothing can replace the experience of getting fully immersed in the rhythm and blues of a
user-interface paradigm. Just as you cannot truly experience music without listening to it, you
cannot truly understand a user-interface with spending a lot of time trying to accomplish many
different real-world tasks using that interface. You are likely to spend some time frustrated as you
try to accomplish tasks that you do easily in other environments, like finding the system task list,
setting the time, or viewing the contents of a directory in the file system. [Comment 6.8]
You are equally likely to enjoy discovering those user-interface elements which do more than
just overcome the apparent limitations of a smart device, but which instead highlight the available
features of a smart device. A simple example of this can be found in Solitaire as implemented on
the SmartPhone (see figure 6-1). On a desktop PC and on a Pocket PC, Solitaire is played by
dragging & dropping cards using the mouse 3 or stylus. The SmartPhone has no explicit pointing
device; the numeric keypad instead provides the means for selecting card locations. As
highlighted by this example, clever use of numeric keys is central to the design of the input to a
SmartPhone program. [Comment 6.9]
Fig ure 6-1 Solitaire on the Smar tPhone [Comment 6.10]
To give you sense of what we are talking about, here are differences that you may notice
when you start using a Pocket PC. This is not meant as an exhaustive list, but rather as a starting
point to encourage you to spend the time getting to know whatever smart device you are targeting
your software to run on. A Pocket PC... [Comment 6.11]
2 At Microsoft, using your own products is referred to as "eating your own dog food" (or
sometimes just "dog fooding"). It is based on the idea – as expressed by Microsoft CEO Steve
Ballmer – that the quality of dog food companies' products would naturally and inevitably improve
if the employees of those companies consumed their own product. All Microsoft employees are
encouraged to eat their own dog food — meaning to make extensive use of their own products.
3
On the desktop, it is possible – but painful – to play Solitaire using the keyboard. This illustrates
an old, but now disregarded principle of Windows user-interface design, which recommends that
mouse and keyboard input be equally supported for all input operations. This is but one element
that separates good software on desktop PCs from great software. Newer software takes a more
mouse-centric approach, workable until a mouse becomes unavailable or disabled.
Chapter 6 – Mouse and Keyboard Input
Page 3
Copyright © 2002 Paul Yao & David Durant
870585272.017.png 870585272.001.png 870585272.002.png 870585272.003.png 870585272.004.png
 
Programming the .NET Compact Framework in VB
By Paul Yao & David Durant
•
has a small (240x320) screen (resolution is one-quarter the minimum VGA,
640x480, rotated by 90 degrees).
•
The screen is covered by a touch-sensitive panel.
•
Character input is accomplished using the Software Input Panel (SIP).
•
The SIP supports both hand-writing recognition and an on-screen keyboard; two of
several input methods. You can write your own input method window (a topic
beyond the scope of this book).
•
Pocket PC applications run full-screen.
•
When you "close" most applications, they minimize (run in the background) instead
of shutting down.
•
The Pocket PC does not completely shut down when you turn the power off. Instead,
the power switch toggles the Pocket PC between a fully-on mode and a suspended
mode. When a smart device is suspended, all applications in memory stay in
memory, but are asleep. This allows a Pocket PC — and many other Windows CE
devices — to support "instant-on."
•
Some Pocket PC applications make extensive use of context or popup menus, which
appear when you tap & hold the stylus on a hot-spot. Examples of context menus
appear in these applications: calendar, contact list, and Pocket Excel.
Event-Driven Input
All GUI systems provide user input as events 4 , because event-drive input works well for the
type of interactive, user-driven approach which GUI systems are built to provide. The event-
driven paradigm pre-dates GUI systems, since interactive simulators and computer games require
such an approach. These exceptions aside, before GUI systems were introduced most computer
software was written to support batch-mode input (some readers may remember punch cards),
screen-oriented forms data entry, and line-oriented input. With the introduction of GUI systems in
the early 1980s, the event-driven paradigm entered the mainstream of computer
programming. [Comment 6.12]
Input events start life as electrical signals that are detected by hardware and transferred by a
device driver into the operating system. The operating system stores this input in a FIFO 5 q ueue,
which a program retrieves by reading the event queue. Some programming interfaces expose the
event retrieval mechanism, while other interfaces hide it. The Win32 API exposes an input loop
— sometimes called the "message loop" or "message pump" — which provides the event source 6 .
By contrast, the message pump is hidden in Microsoft Foundation Class (MFC) programs and
Visual Basic 6 programs. [Comment 6.13]
Th e Compact Framework has a built-in, hidden message pump which lies buried in the
Application 8 class. When the Visual Studio .NET new project wizard creates a C# program,
the static Run method is called in wizard-provided code like the following:
4 This statement holds true for all GUI systems, from the first Apple Macintosh on to the various
members of the Microsoft Windows operating system, all UNIX & Linux-based GUIs, and both the
.NET Framework and the .NET Compact Framework. They might have a different name – Win32
uses the term "message" – and the syntax for retrieving and handling the events may differ, but
the general operation of all GUI systems is essentially the same.
5 FIFO = "first in first out"
6 Win32 programmers will recognize the GetMessage function as the key function in that loop.
7 The System.Windows.Forms.Application class.
8 The System.Windows.Forms.Application class.
Chapter 6 – Mouse and Keyboard Input
Page 4
Copyright © 2002 Paul Yao & David Durant
870585272.005.png
Programming the .NET Compact Framework in VB
By Paul Yao & David Durant
/// <summary>
/// The main entry point for the application.
/// </summary>
static void Main()
{
Application.Run( new Form1());
}
Another static method in the application class, DoEvents , polls the queue for events and delivers
them to their respective targets. That method is equivalent to a standard message pump, which
gets called to help flush messages from the message queue. As we discuss in chapter 15, some
multi-threaded programs need to use this function to allow inter-thread access to controls
(courtesy of the Control.Invoke method.) [Comment 6.15]
When an event enters the operating system queue, its journey is only half over. From the
queue, the event must find its way to the correct window – a "form" or "control" in the
terminology of the Compact Framework – among the many windows in the system. Each window
is owned by a thread, and that thread has a message pump responsible for retrieving the input for
its windows. Each thread, in turn, is owned by an operating system process. The second half of
the journey gets complicated, in short, because the operating system supports multiple processes,
multiple threads, and multiple windows. All the windows sit like baby birds in a nest, opening
and closing their mouths waiting for a mouthful from their mother. The choice of who gets fed is
not arbitrary, but depends on a very specific set of conditions. [Comment 6.16]
In order for a Compact Framework form or control to get mouse or keyboard input, the
following conditions are necessary. Assuming that a given control supports a given event, the
control must... [Comment 6.17]
• be the foreground window (or a child of the foreground window);
• be enabled ( Enabled property = true);
• be visible ( Visible property = true);
• for keyboard input, it must have the focus (call Focus() to set focus to a control);
• for mouse input, the form or control must lie directly under the cursor or under the
stylus (on systems without a cursor).
A few words on each item are in order.
The foreground window
The foreground window is the top-level window that the user has chosen to work with. By
"top-level", we mean windows without a parent. Generally speaking, each program has one top-
level window. And you should allow the user to select which top-level window to work with.
This idea is so important that the Compact Framework does not provide a way to force a window
to the foreground. But the Win32 API does – the SetForegroundWindow function. You need
this function when you have multiple forms in a program and you want to control which form is
visible to the user. Here is the P/Invoke declaration for calling this Win32 function: [Comment
[ DllImport("coredll.dll", CharSet=CharSet.Unicode)]
public static extern int SetForegroundWindow (IntPtr hWnd);
9 The System.Windows.Forms.Application class.
Chapter 6 – Mouse and Keyboard Input
Page 5
Copyright © 2002 Paul Yao & David Durant
870585272.006.png 870585272.007.png 870585272.008.png 870585272.009.png 870585272.010.png 870585272.011.png 870585272.012.png 870585272.013.png 870585272.014.png 870585272.015.png
 

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin