Windows
As Figure 1.2 shows, the heart of the pen-based services for Microsoft Windows
95 consists of two libraries
PKPD.DLL and PENWIN.DLL. The PKPD.DLL file provides ink management for the
pen services of Windows 95. This allows an application to display and manipulate
ink data with any installation of Windows 95, even one without pen hardware.
Chapter 9, "Summary of the Pen Application Programming Interface," identifies the
pen services exported by PKPD.DLL.
The PENWIN.DLL file is available only with original equipment manufacturer
(OEM) pen hardware and provides additional pen services that collect, modify, and
recognize ink data. Before using these input and recognition features, an
application should first test for the presence of the PENWIN.DLL file and either
gracefully exit or alter its behavior accordingly.
In Pen Windows version 1.0, applications were required to call
RegisterPenApp in order to tell the system to convert all edit controls to handwriting edit
(hedit) controls. With Pen API version 2.0, however, this is not necessary; all
edit controls in applications are automatically converted. If the application
is version-stamped as a Windows 95
based application, the conversion is automatic; otherwise, applications
version-stamped as Windows 3.1
based applications require the call to
RegisterPenApp that was required for Pen Windows version 1.0.
It is important to understand that for any application to successfully use the
functions in PENWIN.DLL, the computer on which it is running must load the pen
services when Windows boots and terminated the pen services when Windows shuts
down (that is, PENWIN.DLLmust be referenced from the drivers line in the
[Boot] section of the SYSTEM.INI file). This does not apply to functions in the
PKPD.DLL library, which is automatically available on all Windows 95 systems. See
Appendix C, "Modifying the SYSTEM.INI File," for information on the SYSTEM.INI
file requirements.
Because of this requirement, PENWIN.DLL should never be statically linked by
any application that may be run on a system on which pen services are not
installed. Instead, its functions should always be called using function pointers.
Typically, when the pen-aware application initializes, it calls
GetSystemMetrics with
SM_PENWINDOWS as a parameter which, if returned successful, provides a handle to the loaded
library. Then, for each PENWIN.DLL function used by the application, the
application calls the
GetProcAddress function (with the library handle and the function name) and saves a function
pointer to be used in future calls to that function. See the HFORM sample
application for an example of this technique.
By not linking PENWIN.LIB, it is insured that an application running on a
system on which PENWIN.DLL has not been installed, but which contains PENWIN.DLL on
the path, will not load PENWIN.DLL at runtime. Pen components not loaded at
system boot time are not guaranteed to perform properly. Note that this applies
for both 16-bit and 32-bit libraries.
Applications that are destined to be run only on systems that have pen
services installed can link directly to PENWIN.LIB. These applications should test for
the existence of pen services at startup, however, and exit if it is not
found. Note that most of the examples in this manual follow normal linking practice
for the sake of readability and do not use the safer practice of using function
pointers. It is the responsibility of the developer to choose the best means
of accessing the functions in PENWIN.DLL for each application.
The Pen Message Interpreter provides basic pen services to
pen-unaware applications. Such applications, which do not explicitly take advantage of
Windows pen services, currently represent a majority of Windows-based software.
The Message Interpreter allows use of a pen with pen-unaware programs by
capturing handwritten input and other pen events and converting them into equivalent
keyboard and mouse messages. The application has no knowledge of the pen or that
pen input has occurred.
In capturing handwritten input, the Message Interpreter acts only when it
detects a standard I-beam pointer or insertion point in the pen-unaware
application. Since applications generally show the system I-beam pointer when prompting
for input in writing areas, the Message Interpreter reliably serves most
pen-unaware programs. However, a few pen-unaware Windows-based applications do not
prompt with a standard I-beam pointer, defeating the Interpreter's detection
method. Although the Interpreter still allows the pen to serve as a mouse with such
applications, it cannot interpret handwritten input.
The Message Interpreter may also falter when serving applications developed
for a version of Windows earlier than version 3.1. These applications were not
designed with the pen in mind and therefore may not work optimally with the pen.
For example, edit fields in applications written for Windows version 3.0 are
often too small to write in with a pen. A final problem with older applications
is that the Message Interpreter has no means of receiving contextual information
from the application about what sort of input it expects. This can reduce
recognition accuracy.
The Message Interpreter is of academic interest for the programmer because it
pertains to only pen-unaware applications. The rest of this book focuses on how
to write pen-aware applications and dynamic-link libraries (DLLs) that make
use of the Pen API directly.
- Software for developers
-
Delphi Components
.Net Components
Software for Android Developers
- More information resources
-
MegaDetailed.Net
Unix Manual Pages
Delphi Examples
- Databases for Amazon shops developers
-
Amazon Categories Database
Browse Nodes Database
