![](https://csdnimg.cn/release/download_crawler_static/3775569/bg4.jpg)
Programming the .NET Compact Framework in VB By Paul Yao & David Durant
Chapter 6 – Mouse and Keyboard Input Page 4
Copyright © 2002 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
queue,
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]
The Compact Framework has a built-in, hidden message pump which lies buried in the
Application
9
class. The new project wizard omits a Main function for VB projects, because
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.