As Figure 1.2 shows, the heart of the pen-based services for Microsoft Windows 95 consists of two libraries pics/PENAPI00090001.gif 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 pics/PENAPI00090000.gif based application, the conversion is automatic; otherwise, applications version-stamped as Windows 3.1 pics/PENAPI00090000.gif 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
Unix Manual Pages
Delphi Examples
Databases for Amazon shops developers
Amazon Categories Database
Browse Nodes Database