=============================================================================

****
**** The CDDEML sample can be downloaded from the
**** file 4-56.zip in library section number 4
****

CDDEML: Demonstrates using MFC with DDEML

CDDEML is a sample application written using the
Microsoft(R) Foundation Classes (MFC).

CDDEML contains two applications that demonstrate a DDEML
server and DDEML client in MFC applications. The sample
defines four new classes to help implement the DDEML
support.  These classes are: CDDEClient, CDDEClientConv,
CDDEServer, and CDDEServerConv.

The CDDEClient and CDDEServer classes encasulate the
functionality of a DDEML client or server. The
CDDEClientConv and CDDEServerConv encapsulate individual
conversations which are managed by the CDDEClient or
CDDEServer classes. The CDDEClient and CDDEServer classes
maintain a map of the current conversations acording to
the conversations handle. Using this map a the server or
client can look up any ongoing conversation based on its
handle.

These classes were designed to implement DDEML in a very
general way. As a result, these classes don't do very much
by themselves. They are designed to be reused in an
application by deriving from each of these classes.
Typically, an application will derive one class from
CDDEClient or CDDEServer. The derived class will contain
details such as what conversations are supported, and how
to handle callbacks that don't relate to a specific
conversation. Usually there is only one instance of this
class in an application.  An application may derive many
classes from CDDEClientConv or CDDEServerConv, depending
on how many different types of conversations the
application supports. These derived classes implement how
each conversion handles callbacks. They also may contain
buffers to store data from the
conversation, or pointers to other objects that they need
to comunicate with. The sample contains a client and
server application built using the classes mentioned
above.

One difficulty in writting DDEML classes, is how to handle
the DDEML callback function. In this sample, the DDEML
callback function is containted in the CDDEClient or
CDDEServer class.  The callback function first checks to
see if the transaction is for the client or server, or for
one of the conversations. If it is for the client or
server, then the callback function calls the member
function that handles that transaction.

If the transaction is for a conversation, the the callback
function looks up the pointer to the conversation object
using the handle of the conversation in the conversation
map. Then it calls the member function of the conversation
that handles that transaction. Therefore, by using these
classes, an application developer does not need to write a
DDEML callback function.

CDDEML requires Microsoft C/C++ version 7.0. It was built
and tested with Microsoft Windows(TM) version 3.1.

KEYWORDS: CD3; afx

=============================================================================

=============================================================================

****
**** The MFCDIB sample can be downloaded from the
**** file 4-2.zip in library section number 4
****

MFCDIB: Defines a DIB Using MFC

MFCDIB is a Microsoft(R) Foundation Class (MFC) sample
that demonstrates a technique for implementing a CDIB
class. The CDIB class defines an object that represents a
device-independent bitmap (DIB). MFCDIB can load, save,
display, copy, paste, and serialize a CDIB object.

The CDIB class is derived from CObject. The CDIB class is
implemented by calling prewritten C routines from the
DIBUTIL.DLL library, which contains many high-level
functions for DIB manipulation.

MFCDIB requires Microsoft C/C++ version 7.0 and the
Microsoft Windows(TM) version 3.1 Software Development Kit
(SDK) libraries.

KEYWORDS: PR-CD2; afx

=============================================================================

=============================================================================

****
**** The MODELESS sample can be downloaded from the
**** file 4-4.zip in library section number 4
****

MODELESS: Defines a Modeless Dialog Box Using MFC

MODELESS creates and displays a modeless dialog box by
deriving a class from CDialog. The main window object
contains a pointer to the modeless dialog object. When the
user selects the menu item to display the modeless dialog
box, MODELESS creates and displays the modeless dialog
object, and disables the menu item. When the user closes
the dialog box, MODELESS destroys the dialog box with
DestroyWindow and deletes its memory. A message posted to
the main window enables the menu item for displaying the
modeless dialog box.

MODELESS uses three classes inherited from CDialog,
CWinApp, and CFrameWnd.

KEYWORDS: PR-CD2; afx

=============================================================================

=============================================================================

****
**** The SUBCLASS sample can be downloaded from the
**** file 4-4.zip in library section number 4
****

SUBCLASS: Subclasses an Edit Control Using MFC

SUBCLASS subclasses an edit control in a dialog box and
makes it accept either numbers or letters. SUBCLASS uses
five classes inherited from CEdit, CSubclassedEdit,
CModalDialog, CWinApp, and CFrameWnd.

SUBCLASS subclasses a window by replacing the window
procedure for that window with AfxWndProc, and attaching
the window to a CWnd object. MFC provides two functions to
subclass a window: SubclassWindow and SubclassDlgitem.
These functions store the old window procedure in the
location returned by GetSuperWndProcAddr.

To change the behavior of the target window, SUBCLASS
overloads the appropriate functions for the CWnd object.

You can change the behavior of a subclassed window by
subclassing it with a different CWnd object. Before
calling the subclassing function on that window, you must
first "unsubclass" the window. MFC does not provide a
function to unsubclass a window. You must call
::SetWindowLong to replace the AfxWndProc with the
original window procedure, then detach the CWnd object
from the target window.

SUBCLASS subclasses an edit control in a dialog box to
accept either numbers or letters. The CSubclassedEdit
class is derived from CEdit, and UnSubclass is declared as
its member function. Two additional classes
(CSubNumberEdit and CSubLetterEdit) are derived from
CSubclassedEdit to provide the two behaviors for the edit
control. The OnChar function is overloaded for both of
these classes.

The dialog-box class is derived from CModalDialog and has
two member data objects: SubNumberEdit and CSubLetterEdit.

KEYWORDS: PR-CD2; afx

=============================================================================

=============================================================================

****
**** The BALLCLI sample can be downloaded from the
**** file 4-5.zip in library section number 4
****

BALLCLI: DDEML Client Demonstrates DDEML with Bouncing
Ball

Revised: November 25, 1992

BALLCLI is a companion program for the BALLSRV sample
application.

BALLSRV and BALLCLI demonstrate the basic concepts of the
dynamic data exchange management library (DDEML) protocol
and the correct method for implementing DDEML in an
application. Although DDEML is a new concept in
Microsoft(R) Windows(TM) version 3.1, a DDEML application
will run without problems in Windows version 3.0 if the
DDEML.DLL file is added to the Windows version 3.0
installation. An application that uses DDEML for DDE can
establish a conversation with an application using the
Windows version 3.0 DDE convention.

BALLSRV and BALLCLI demonstrate DDE by creating a ball and
bouncing it between the server application window and the
client application window. BALLSRV creates a purple ball
and bounces it into the BALLCLI window. BALLCLI creates a
green ball and bounces it into the BALLSRV window. In this
configuration, each application acts as the server for the
ball it creates and the client for the other ball.

BALLSRV acts as server when the purple ball reaches the
right edge of its window. At this point, BALLSRV advises
BALLCLI that the purple ball will bounce into its window.
(The applications assume that the BALLSRV window is always
on the left and the BALLCLI window is always on the
right.) Similarly, BALLCLI acts as server when the green
ball reaches the left edge of its window. At this point,
BALLCLI advises BALLSRV that the green ball will bounce
into its window. In each case, the application that
receives data acts as the client.

BALLCLI and BALLSRV also let the user change the speed at
which the ball bounces. The Speed option on the BALLSRV
window changes the speed of the purple ball, and the Speed
option on the BALLCLI window changes the speed of the
green ball. Whenever the user changes the speed of a ball,
the window containing the ball is notified through a DDEML
transaction. In the same manner, when the size of one
window changes, the size of the other window changes as
well.

BALLCLI was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: DdeClientTransaction; DdeConnect;
DdeCreateStringHandle; DdeDisconnect; DdeFreeStringHandle;
DdeInitialize; DdeNameService; DdePostAdvise;
DdeUninitialize; XTYP_ADVDATA; XTYP_ADVREQ; XTYP_ADVSTART;
XTYP_ADVSTOP; XTYP_CONNECT; XTYP_CONNECT_CONFIRM;
XTYP_DISCONNECT; AppendMenu; BitBlt; CheckMenuItem;
CreateCompatibleDC; DeleteObject; FindWindow;
GetDlgItemText; GetSystemMenu; GetWindowRect; LoadBitmap;
LoadIcon;LoadString;PatBlt;SelectObject;
SetDlgItemText;SetWindowPos;StretchBlt;
WM_GETMINMAXINFO;WM_MOVE; WM_QUERYDRAGICON; WM_SIZE;
WM_SYSCOMMAND; WM_TIMER;



=============================================================================

=============================================================================

****
**** The BALLSRV sample can be downloaded from the
**** file 4-57.zip in library section number 4
****

BALLSRV: DDEML Server Demonstrates DDEML with Bouncing
Ball

Revised: November 25, 1992

BALLSRV is a companion program for the BALLCLI sample
application.

BALLSRV and BALLCLI demonstrate the basic concepts of the
dynamic data exchange management library (DDEML) protocol
and the correct method for implementing DDEML in an
application. Although DDEML is a new concept in
Microsoft(R) Windows(TM) version 3.1, a DDEML application
will run without problems in Windows version 3.0 if the
DDEML.DLL file is added to the Windows version 3.0
installation. An application that uses DDEML for DDE can
establish a conversation with an application using the
Windows version 3.0 DDE convention.

BALLSRV and BALLCLI demonstrate DDE by creating a ball and
bouncing it between the server application window and the
client application window. BALLSRV creates a purple ball
and bounces it into the BALLCLI window. BALLCLI creates a
green ball and bounces it into the BALLSRV window. In this
configuration, each application acts as the server for the
ball it creates and the client for the other ball.

BALLSRV acts as server when the purple ball reaches the
right edge of its window. At this point, BALLSRV advises
BALLCLI that the purple ball will bounce into its window.
(The applications assume that the BALLSRV window is always
on the left and the BALLCLI window is always on the
right.) Similarly, BALLCLI acts as server when the green
ball reaches the left edge of its window. At this point,
BALLCLI advises BALLSRV that the green ball will bounce
into its window. In each case, the application that
receives data acts as the client.

BALLCLI and BALLSRV also let the user change the speed at
which the ball bounces. The Speed option on the BALLSRV
window changes the speed of the purple ball, and the Speed
option on the BALLCLI window changes the speed of the
green ball. Whenever the user changes the speed of a ball,
the window containing the ball is notified through a DDEML
transaction. In the same manner, when the size of one
window changes, the size of the other window changes as
well.

BALLSRV was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: DdeClientTransaction; DdeConnect;
DdeCreateStringHandle; DdeDisconnect; DdeFreeStringHandle;
DdeInitialize; DdeNameService; DdePostAdvise;
DdeUninitialize; XTYP_ADVDATA; XTYP_ADVREQ; XTYP_ADVSTART;
XTYP_ADVSTOP; XTYP_CONNECT; XTYP_CONNECT_CONFIRM;
XTYP_DISCONNECT; AppendMenu; BitBlt; CheckMenuItem;
CreateCompatibleDC; DeleteObject; FindWindow;
GetDlgItemText; GetSystemMenu; GetWindowRect; LoadBitmap;
LoadIcon;LoadString;PatBlt;SelectObject;
SetDlgItemText;SetWindowPos;StretchBlt;
WM_GETMINMAXINFO;WM_MOVE; WM_QUERYDRAGICON; WM_SIZE;
WM_SYSCOMMAND; WM_TIMER;



=============================================================================

=============================================================================

****
**** The DMLCLT sample can be downloaded from the
**** file 4-7.zip in library section number 4
****

DMLCLT: Demonstrates Basic DDEML Client Communications

DMLCLT is a companion program for the DMLSRV sample
application. These two applications show basic dynamic
data exchange management library (DDEML) communications
between a server and a client. DMLCLT and DMLSRV
demonstrate connect, request, asynchronous, hot advise
loop, and warm advise loop transactions.

>  Connect: The client connects to the server to initiate
a conversation. DMLCLT uses the DdeConnect function to
start a general conversation (which deals with text and
bitmaps) and a SYSTEM conversation (which supports the
system topic).

>  Request: When the client needs information from the
server, it calls the DdeClientTransaction(...XTYP_REQUEST)
function. DMLCLT demonstrates several types of requests.

>  Asynchronous transaction: DMLCLT starts an asynchronous
transaction with the server to request information that
may not be ready at the time of the request. DMLCLT starts
this transaction when the user selects the Asynchronous
Transaction command from the Transactions menu. When the
server receives the request (as an XTYP_REQUEST
transaction), it prompts the user for the number of window
bitmaps the client should display and returns a data
handle containing the number from its callback function.
The DDEML sends the client a XTYP_XACT_COMPLETE to
indicate that the server has finished the transaction. The
client then displays the desired number of bitmaps. The
asynchronous transaction ensures that the transaction will
not time out before the user has a chance to close the
dialog box.

>  Hot Advise Loop: When a hot advise loop is established
between a client and a server, the server notifies the
client (through an XTYP_ADVDATA) each time data changes.
The notification includes a handle to the changed data.
When you choose the Change Bitmap command from the DMLSRV
window, the server notifies the client that the bitmap has
changed (this notification includes a handle to the
changed bitmap). The client then displays the bitmap in
its window.

>  Warm Advise Loop: When a warm advise loop is
established between a client and a server, the server
notifies the client that the specified data has changed,
but it does not send the client the changed data by
default. DMLCLT displays a message box asking the user if
the client window should be updated with the bitmap from
the server. If the user selects Yes, the client requests
the data containing the changed bitmap from the server
through the DdeClientTransaction(...XTYP_REQUEST)
function.

DMLCLT was built and tested under Microsoft(R) Windows(TM)
version 3.1.

=============================================================================

=============================================================================

****
**** The DMLSRV sample can be downloaded from the
**** file 4-8.zip in library section number 4
****

DMLSRV: Demonstrates Basic DDEML Server Communications

DMLSRV is a companion program for the DMLCLT sample
application. These two applications show basic dynamic
data exchange management library (DDEML) communications
between a server and a client. DMLCLT and DMLSRV
demonstrate connect, request, asynchronous, hot advise
loop, and warm advise loop transactions.

>  Connect: The client connects to the server to initiate
a conversation. DMLCLT uses the DdeConnect function to
start a general conversation (which deals with text and
bitmaps) and a SYSTEM conversation (which supports the
system topic).

>  Request: When the client needs information from the
server, it calls the DdeClientTransaction(...XTYP_REQUEST)
function. DMLCLT demonstrates several types of requests.

>  Asynchronous transaction: DMLCLT starts an asynchronous
transaction with the server to request information that
may not be ready at the time of the request. DMLCLT starts
this transaction when the user selects the Asynchronous
Transaction command from the Transactions menu. When the
server receives the request (as an XTYP_REQUEST
transaction), it prompts the user for the number of window
bitmaps the client should display and returns a data
handle containing the number from its callback function.
The DDEML sends the client a XTYP_XACT_COMPLETE to
indicate that the server has finished the transaction. The
client then displays the desired number of bitmaps. The
asynchronous transaction ensures that the transaction will
not time out before the user has a chance to close the
dialog box.

>  Hot Advise Loop: When a hot advise loop is established
between a client and a server, the server notifies the
client (through an XTYP_ADVDATA) each time data changes.
The notification includes a handle to the changed data.
When you choose the Change Bitmap command from the DMLSRV
window, the server notifies the client that the bitmap has
changed (this notification includes a handle to the
changed bitmap). The client then displays the bitmap in
its window.

>  Warm Advise Loop: When a warm advise loop is
established between a client and a server, the server
notifies the client that the specified data has changed,
but it does not send the client the changed data by
default. DMLCLT displays a message box asking the user if
the client window should be updated with the bitmap from
the server. If the user selects Yes, the client requests
the data containing the changed bitmap from the server
through the DdeClientTransaction(...XTYP_REQUEST)
function.

DMLSRV was built and tested under Microsoft(R) Windows(TM)
version 3.1.

=============================================================================

=============================================================================

****
**** The BMUTIL sample can be downloaded from the
**** file 4-9.zip in library section number 4
****

BMUTIL: Demonstrates Bitmap Manipulation Techniques

BMUTIL illustrates four bitmap manipulation techniques:

>  Creating a "grayed" or "disabled" bitmap from a color
bitmap

>  Changing a single color in a bitmap without affecting
other colors

>  Swapping two colors in a bitmap without affecting other
colors

>  Dithering a color bitmap to a monochrome bitmap

You can choose an option from the Process menu to change
colors, dither, or restore the bitmap.

BMUTIL uses functions from the DIBAPI library, which was
written by Microsoft(R) Developer Support. DIBAPI contains
routines that handle common device-independent bitmap
(DIB) operations, such as loading a .BMP file and
converting DIBs to device-dependent bitmaps (DDBs).

Since the intent of the sample is to demonstrate the four
bitmap manipulation techniques listed above rather than
the DIB techniques in the DIBAPI library, the library is
provided in binary form only. To view the DIBAPI.DLL
source code, see the WINCAP sample application on the
Microsoft Developer Network CD.

BMUTIL was built and tested under Microsoft Windows(TM)
version 3.1.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The DRAGBMP sample can be downloaded from the
**** file 4-10.zip in library section number 4
****

DRAGBMP: Demonstrates Smooth Bitmap Dragging

DRAGBMP shows how to drag images smoothly on the screen.
This is achieved through the use of several bitmaps and a
series of BitBlt operations.

Before you can drag a bitmap, you must store the following
information:

1.  A bitmap of the desired image, such as the cards in
Solitaire or the domino used in this sample.

2.  A bitmap of what lies underneath the desired image.
This information is necessary to redraw the underlying
area when the image is dragged elsewhere.

3.  The current position of the image (you can also store
or retrieve the width and height of the image using
GetObject on the image's bitmap).

Once this information is stored, the image is ready to
drag. The user selects the image by clicking the left
mouse button when the mouse pointer is on the image, drags
the image by moving the mouse while the mouse button is
depressed, and ends the dragging by releasing the mouse
button.

In this sample, the image is a yellow domino. Choose Draw
Image! to draw the domino, then drag the domino using the
mouse. Hit-testing in WM_LBUTTONDOWN determines when the
domino is selected. Once selected, the dragging process
begins. On each WM_MOUSEMOVE, a new background bitmap is
created, the old background bitmap is restored, and the
domino is moved to its new location. The WM_LBUTTONUP
message ends the dragging process.

(x',y')
+------------------------- new position
|\                       |
| \(dx,dy)               |
|  \                     |
|   + . . . . . . . . . . . . . . . . . old position
|   .(x,y)               |            .
|   .                    |            .
|   .                    |            .
----.---------------------            .
.                                 .
.                                 .
. . . . . . . . . . . . . . . . . .


The basic steps to perform the bitmap dragging are as
follows:

1.  Calculate the delta x and delta y in the mouse
movement (dx,dy).

2.  BitBlt the screen at the new position onto a new
bitmap. This corresponds to a rectangle with origin at
(x',y') in the figure above, and becomes the new
background bitmap.

3.  Since the new background bitmap still contains part of
the domino's image starting at point (x,y) in the figure
above, BitBlt the old background bitmap to that point on
the new background bitmap, offsetting it by dx and dy. The
resulting bitmap contains the correct background for the
new position.

4.  BitBlt the domino's bitmap to the screen at its new
location: origin at point (x',y') in the figure above.

5.  The domino is now in the correct position on the
screen and we have a bitmap of what is underneath, but a
portion of the domino still appears at the lower right. To
erase this portion, first BitBlt the bitmap of the domino
onto the old background's bitmap, offsetting it by -dx and
-dy, and then BitBlt this modified old background bitmap
to the screen at point (x,y). This erases the old portion
of the domino without flashing.

6.  Dragging is now complete. Store the new background
bitmap and delete the old one.

The DRAG.C file contains the code for dragging and hit-
testing. The MAINWND.C file contains the code for
processing the mouse and paint messages.

DRAGBMP was built and tested under Microsoft(R)
Windows(TM) version 3.1.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The FADE sample can be downloaded from the
**** file 4-11.zip in library section number 4
****

FADE: Fades Bitmaps Using Palette Animation

FADE loads, generates, saves, and "fades" special device-
independent bitmaps (DIBs) built from two component DIBs.
The fading technique involves animating a palette matrix
built from the two component palettes. For more
information, see the README.TXT file.

The dual DIBs created by FADE are 8 bytes per pixel (bpp)
but the component DIBs must be 4 bpp. FADE automatically
converts monochrome DIBs to 4 bpp before building the
resultant DIB, but prompts you before converting higher-
resolution DIBs down to 4 bpp. (This conversion does not
include color analysis.)

FADE depends on the Microsoft(R) Windows(TM) palette and
will not run if the video display does not support
palettes. For example, FADE does not run on a standard VGA
display, but runs on most 256-color displays.

To see the application in action, open one of the .BM2
files included with FADE and manipulate the scroll bar and
animation settings. (Keep in mind that what you see has
nothing to do with BitBlt's.)

FADE was built and tested under Microsoft Windows version
3.1.

KEYWORDS: PR-CD2; ScreenToClient; MoveWindow;
CreatePalette; SelectPalette; RealizePalette;
CreateCompatibleDC; GetStockObject; AnimatePalette;
InflateRect; CreateSolidBrush; PatBlt; GetNearestColor;
GetSysColor; CreateDIMap; GetDIBits; CreateDIBPalette;
DIBToBitmap; _lread; _hread; _lclose; SetSystemPaletteUse

=============================================================================

=============================================================================

****
**** The GDIRSRCS sample can be downloaded from the
**** file 4-58.zip in library section number 4
****

GDIRSRCS: Extracts Resources from Resource Files

GDIRSRCS demonstrates how to create icons, cursors, and
bitmaps from their respective resource files. It also
shows how to read a resource file and create other
resources from that information. For example, GDIRSRCS:

>  Reads a bitmap resource file and creates a bitmap,
icon, and cursor.

>  Reads a cursor resource file and creates a cursor,
bitmap, and icon.

>  Reads an icon resource file and creates an icon,
cursor, and bitmap.

Use the Open Resources and Convert Resources menus to read
and create bitmaps, cursors, and icons.

The device-independent bitmaps (DIBs) for icons and
cursors are assumed to be in Microsoft(R) Windows(TM)
version 3.0 format. The DIBs for bitmaps, however, can be
in Windows version 3.0 or in OS/2(R) format. GDIRSRCS
converts OS/2 DIBs into Windows version 3.0 DIBs before
processing the DIB.

GDIRSRCS was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The GDIWATCH sample can be downloaded from the
**** file 4-13.zip in library section number 4
****

GDIWATCH: Uses Tool Helper Library to Walk Heap

GDIWATCH shows how to use the functions in the tool helper
library (TOOLHELP.DLL) to walk the graphics device
interface (GDI) and User local heaps.

The DLL exports a very primitive application programming
interface. It contains the following two functions:


void FAR PASCAL TakeSnapShot(HWND hWndParent, int
iHeapMarker);
void FAR PASCAL Compare(HWND hWndParent, int
iHeapMarker,
int iNewMessage);

Do not mismatch IDM_GDIHEAP and IDM_USERHEAP when using
TakeSnapShot and Compare; it will produce random garbage
data. All identifiers are defined in WATCHLIB.H.

GDIWATCH was built and tested under Microsoft(R)
Windows(TM) version 3.1.

KEYWORDS: PR-CD2; CreateFontIndirect; LocalFirst;
LocalNext; _fmemcpy; LocalLock; LocalUnlock

=============================================================================

=============================================================================

****
**** The MAPMODE sample can be downloaded from the
**** file 4-14.zip in library section number 4
****

MapMode: Demonstrates Mapping Modes

MapMode lets you experiment with the mapping mode
attributes of a device context (DC). You can use the
controls in the Mapping Mode Settings dialog box to change
the mapping mode, window origin, window extents, viewport
origin, and viewport extents.

KEYWORDS: PR-CD2; modeless; LoadBitmap; SetBkColor;
SetMapMode; SetWindowOrg; SetViewportOrg; GetMMData;
DPtoLP; SetWindowExt; SetViewportExt

=============================================================================

=============================================================================

****
**** The PRNCDLG sample can be downloaded from the
**** file 4-59.zip in library section number 4
****

PRNCDLG: Demonstrates Printing Functions and Common Dialog
Boxes

PRNCDLG shows how to use the new printing functions
available in Microsoft(R) Windows(TM) version 3.1:
SetAbortProc, StartDoc, EndDoc, StartPage, and EndPage.

The sample also demonstrates the use of the ChooseFont and
Print common dialog boxes provided by the common dialog
box dynamic-link library (COMMDLG.DLL). The user can
select a font and display a line of text on the screen
using that font, or print the line on a printer selected
through the Print common dialog box.

PRNCDLG is included in the Microsoft Knowledge Base
Software/Data Library. Please search on the numbers
prefixed with "S" and "Q" in the Keywords section below
for more information on this sample application.

PRNCDLG was built and tested under Microsoft Windows
version 3.1 and Microsoft C/C++ version 7.0.

KEYWORDS: CD3; S13293; Q81337

=============================================================================

=============================================================================

****
**** The RLEAPP sample can be downloaded from the
**** file 4-15.zip in library section number 4
****

RLEAPP: Demonstrates Animations Using DIB RLE Format

RLEAPP loads, generates, plays and saves animations using
the device-independent bitmap (DIB) run-length encoding
(RLE) format for delta frames.

The RLE format is described in the following
documentation:

>  The Microsoft(R) Windows(TM) version 3.0 Software
Development Kit (SDK): "Reference--Volume 1," in the
section on the BITMAPINFOHEADER structure.

>  The Microsoft Windows version 3.1 SDK: "Programmer's
Reference, Volume 3: Messages, Structures, and Macros," in
the section on BITMAPINFOHEADER.

>  The Multimedia Development Kit (MDK): "Programmer's
Reference," in the "Windows 3.0 Bitmap Compression
Formats" section.

RLEAPP handles only 8-bits-per-pixel DIBS, although the
same technology applies to 4-bits-per-pixel DIBs (RLE,
delta frame, and so on).

RLEAPP source code includes many optimizations for 80386-
specific machines. This is a very useful way to increase
speed because the MPC specification calls for a machine
that uses a 80386 or higher processor, so in most cases,
the 80286 support can be left out.

RLEAPP is very dependent on the BitBlt function speed of
the video card and driver. In most cases, the video driver
is very slow doing BitBlt. Comments on speed should be
directed to the video card manufacturer, who is
responsible for this code. The speed to BitBlt a 160x120
256-color frame (with the same palette) is approximately
15 frames per second. The BitBlt speed for slow drivers or
cards is about 1 frame per second.

RLEAPP was built and tested under Microsoft Windows
version 3.1.



=============================================================================

=============================================================================

****
**** The TTDMP sample can be downloaded from the
**** file 4-60.zip in library section number 4
****

TTDMP: Demonstrates TrueType Functions and Structures

TTDMP shows how to use the TrueType(R)
GetOutlineTextMetrics and GetRasterizerCaps functions
provided in Microsoft(R) Windows(TM) version 3.1, and
displays the contents of the OUTLINETEXTMETRIC,
TEXTMETRIC, PANOSE, and LOGFONT structures that describe a
TrueType font.

The sample also demonstrates the use of the ChooseFont and
Print common dialog boxes provided by the common dialog
box dynamic-link library (COMMDLG.DLL). The user can
select a font and display a line of text on the screen
using that font, or print the line on a printer selected
through the Print common dialog box.

TTDMP is included in the Microsoft Knowledge Base
Software/Data Library. Please search on the numbers
prefixed with "S" and "Q" in the Keywords section below
for more information on this sample application.

TTDMP was built and tested under Microsoft Windows version
3.1 and Microsoft C/C++ version 7.0.

KEYWORDS: CD3; S13382; Q82233

=============================================================================

=============================================================================

****
**** The WINCAP sample can be downloaded from the
**** file 4-16.zip in library section number 4
****

WINCAP: Captures Screens Using DIB API

WINCAP demonstrates how to capture, save, and print the
entire screen, portions of the screen, or specific
windows. The program also defines routines that accomplish
common device-independent bitmap (DIB) functions; these
routines form the DIB application programming interface
(API). WINCAP uses the DIB API functions for most of the
screen capture, printing, and saving work. See the
DIBAPI.TXT file for a description of the DIB API
functions.

WINCAP illustrates the following techniques:

>  Capturing the screen (or a specific window) into a DIB

>  Capturing the screen to a device-dependent bitmap (DDB)

>  Printing a DIB using banding

>  Loading and saving a DIB to a disk file (.BMP file)

>  Converting between DIBs and DDBs

>  Displaying the captured screen DDB

All of these techniques call the DIB API. WINCAP includes
the source code for these functions. You can call these
functions easily from a different application by simply
compiling the enclosed DIBAPI.DLL, and linking with the
DIBAPI.LIB import library.

The preferred way to capture a screen in Microsoft(R)
Windows(TM) is to copy the screen pixels into a DIB, and
then to use this DIB in subsequent operations (for
example, to save the bitmap to a file or print the
bitmap).

If you do not use a DIB in the intermediate step, the
results of the screen print may be less than desirable. If
you use a DIB to hold the screen image, device-dependent
information is removed from the bitmap. This simplifies
the process of displaying the image on devices with
different display capabilities. For instance, capturing a
screen from a 24-bit display adapter and printing it on a
1-bit (monochrome) printer can produce exceptional results
if DIBs are used. Additionally, many printer drivers
implement gray-scale dithering; the output on these
printers is also excellent when DIBs are used.

NOTE:  Because bitmaps are device-dependent, you should
avoid the BitBlt function when printing bitmaps. The type
of bitmaps that the BitBlt function requires are normally
in the format of the display driver rather than the
printer driver. Depending on the drivers involved, the
results of using BitBlt to print a bitmap can vary from
extremely poor output quality to no output at all.

Although all printer drivers are able to BitBlt a
monochrome bitmap to the printer, this technique generally
produces poor results because the printer cannot apply
gray-scaling to the image.

This technique of using a DIB to convert a bitmap between
display devices with different capabilities can also be
used to convert bitmaps while preserving the original
color information (for example, loading a 256-color bitmap
from a .BMP file and printing it to a 3-color printer or
displaying it on a 24-bit display).

The file DIBAPI.TXT contains more information on function
parameters and usage. A Windows Help file for the DIB APIs
is also included.

WINCAP was built and tested under Microsoft Windows
version 3.1.



=============================================================================

=============================================================================

****
**** The BACKGRND sample can be downloaded from the
**** file 4-18.zip in library section number 4
****

BACKGRND: Demonstrates Background Processing

BACKGRND uses a PeekMessage loop to do background
processing. The background task is to draw random
rectangles. BACKGRND draws one "batch" of rectangles with
each PeekMessage loop. The rectangles in each batch are
drawn in the same color, providing a visual indication of
how much background work is being done before BACKGRND
offers to yield. You can change both the "batch size" and
the total number of rectangles to be drawn through menu
options.

BACKGRND does not replace the main GetMessage loop with a
PeekMessage loop. Instead, it enters a PeekMessage loop
only when the user chooses the Draw! command.

For more information on BACKGRND, please see the module
and function headers in the source code.

BACKGRND was built and tested under Microsoft(R)
Windows(TM) version 3.1.

KEYWORDS: PR-CD2; GetClientRect; ClientToScreen;
ScreenToClient; SetFocus; SetRect; SetTextColor;
ExtTextOut; SetBkColor; LoadIcon; LoadCursor; Rectangle

=============================================================================

=============================================================================

****
**** The MAKEAPP sample can be downloaded from the
**** file 4-19.zip in library section number 4
****

MAKEAPP: Generates a Microsoft Windows-based Application

MAKEAPP illustrates the use of the WINDOWS.H STRICT option
and provides examples of the following WINDOWSX.H
features: message crackers, control functions, and macro
functions.

You can run the MAKEAPP.BAT batch file to create a new
Windows(TM)-based application. MAKEAPP changes the names
of files, constants, and functions to names that you
specify and creates a clone of the MAKEAPP application
project. For more information, see the MAKEAPP.TXT and
WINDOWSX.TXT files.

MAKEAPP was built and tested under Microsoft(R) Windows
version 3.1.

=============================================================================

=============================================================================

****
**** The RESEXT sample can be downloaded from the
**** file 4-61.zip in library section number 4
****

RESEXT: Extracts Resources from .EXE and .LIB Files

RESEXT extracts information from an executable file
without requiring the application to be loaded. The
Microsoft(R) Windows(TM) Program Manager uses this
procedure when it extracts an icon from the .EXE file to
represent the application. An .EXE file or a dynamic-link
library (DLL) contains other resources and tables that may
be useful to certain applications. RESEXT demonstrates how
to extract and decode these resources for executable or
library files. (FONTS and DRVs qualify as DLLs.)

RESEXT uses the old and new header formats as documented
in "The MS-DOS(R) Encyclopedia," by Ray Duncan (Microsoft
Press, 1988). RESEXT loads these headers, the resource
table, and the icon, cursor, and bitmap resources found in
the resource table and lets you save the resources in
files.

For more information on file and resource formats, see
"The MS-DOS Encyclopedia" or "What's in There? Windows 3.0
Executable and Resource File Formats Revealed!" by Kevin
P. Welch (Microsoft Systems Journal, Vol. 6, No. 5).

RESEXT was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: CD3

=============================================================================

=============================================================================

****
**** The SHOWGRP sample can be downloaded from the
**** file 4-20.zip in library section number 4
****

SHOWGRP: Reads Group Files

SHOWGRP demonstrates how to read group files. The group
file format is documented in the Microsoft(R) Windows(TM)
version 3.1 Software Development Kit (SDK) "Programmer's
Reference."

SHOWGRP was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: PR-CD2; LoadString; GetPrivateProfileString;
SetMapMode; DrawIcon

=============================================================================

=============================================================================

****
**** The VERSTAMP sample can be downloaded from the
**** file 4-21.zip in library section number 4
****

VERSTAMP: Accesses the Version Information Resource for a
File

VERSTAMP demonstrates how to use the VER.DLL and VER.LIB
libraries, which provide version-stamping for Microsoft(R)
Windows(TM) and MS-DOS(R) executable files.

Use the Open command from the File menu to select a source
file and to display its file version information in the
main window. If the file does not have a version
information resource, VERSTAMP notifies you with a message
box. If the file has a version information resource, press
the More Info button in the main window to display the
information. If you press the Install File button,
VERSTAMP uses the VerFindFile function to determine where
the source file should be installed. If VerFindFile
returns an error, VERSTAMP displays a message box
prompting you to continue or to quit. If you choose to
continue, VERSTAMP proceeds with the installation,
captures the result of VerInstallFile, and displays it in
a message box.

VERSTAMP was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: GetFileVersionInfo; GetFileVersionInfoSize;
GetSystemDirectory; GetWindowsDirectory; VerLanguageName;
VerQueryValue

=============================================================================

=============================================================================

****
**** The WINQUERY sample can be downloaded from the
**** file 4-22.zip in library section number 4
****

WINQUERY: Demonstrates SQL Server Query

WINQUERY demonstrates ad-hoc queries in Microsoft(R) SQL
Server. It multitasks to do background query processing
using a PeekMessage loop.

WINQUERY requires three SQL Server files to build, and two
SQL files to run. The three SQL Server include files come
with the SQL Server Programmer's Toolkit for C:
SQLFRONT.H, SQLDB.H, and W3DBLIB.LIB along with the two
SQL Server run-time files:W3DBLIB.DLL and DBNMP3.DLL.

WINQUERY was built and tested under Microsoft Windows(TM)
version 3.1 and SQL Server PTK for C version 4.2 A.

KEYWORDS: PR-CD2; GetStockObject; SendMessage; TextOut

=============================================================================

=============================================================================

****
**** The XTENSION sample can be downloaded from the
**** file 4-23.zip in library section number 4
****

XTENSION: Extension DLL for File Manager

XTENSION is an extension dynamic-link library (DLL) that
adds administration support features such as file and disk
utilities to Microsoft(R) Windows(TM) File Manager.
XTENSION contains an entry point to process menu commands
and notification messages sent by File Manager and can
retrieve information about File Manager windows.

XTENSION adds a menu called Extension to File Manager and
processes all messages that File Manager sends to an
extension DLL. It also creates a status window using the
DLL's instance handle and adds the following commands to
the File Manager Extension menu:

>  Status Window: Shows/hides status window.

>  Selected File(s) Size: Displays disk space taken by the
files.

>  Selected Drive Info: Displays selected drive
information.

>  Focused Item Info: Displays the name of the selected
item.

>  Reload Extension: Reloads this extension.

>  Refresh Window: Refreshes File Manager's active window.

>  Refresh All Windows: Refreshes all File Manager
windows.

>  About Extension: Displays About dialog box.

To load XTENSION.DLL as a File Manager extension, add the
following lines to the WINFILE.INI initialization file:

[AddOns]
SDK Demo Extension=<path to XTENSION.DLL>

File Manager installs the extensions that have entries in
the [AddOns] section of WINFILE.INI. Each entry consists
of a tag and a value.

The File Manager extensions are new in Microsoft Windows
version 3.1. For information on relevant functions and
messages, see the Windows version 3.1 Software Development
Kit (SDK) "Programmer's Reference" manual.

XTENSION was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: FMExtensionProc; FM_GETFOCUS;
FM_REFRESH_WINDOWS; FMEVENT_INITMENU; FMEVENT_LOAD;
FMEVENT_SELCHANGE; FMEVENT_UNLOAD; FMEVENT_USER_REFRESH;
FMS_GETDRIVEINFO; FMS_GETFILESEL

=============================================================================

=============================================================================

****
**** The BADAPP sample can be downloaded from the
**** file 4-24.zip in library section number 4
****

BADAPP: Demonstrates "Bad Application" Handling

BADAPP is an application designed for Microsoft(R)
Windows(TM) versions 3.0 and 3.1 that can generate a GP
fault and hang after receiving input. Its purpose is to
demonstrate how Windows version 3.1 handles "bad
applications."

WARNING:  Before running BADAPP, save your work and close
all other applications to avoid any problems that the GP
fault or hang may cause.

When you choose GP-Fault or Hang from the Action menu, the
"fuse" in the display area burns down before the GP fault
occurs. If you have a multimedia system, the burning fuse
will be accompanied by sound effects. You can choose
Options from the Action menu to disable the sound, to
modify the zoom factor, and to change the visible
application title (limited to eight characters).

BADAPP was built with Microsoft QuickC(R) version 1.0. The
fuse icons were created using the IconWorks sample
application from Visual Basic(TM) version 1.0. ICO2BMP.EXE
was used to convert the FUSE*.ICO and BOOM*.ICO files to
FUSE*.BMP and BOOM*.BMP files.

BADAPP was built and tested under Microsoft Windows
version 3.1.



=============================================================================

=============================================================================

****
**** The DLLFLOAT sample can be downloaded from the
**** file 4-25.zip in library section number 4
****

DLLFLOAT: Converts Floating Points to Character Strings

DLLFLOAT demonstrates a function in a dynamic-link library
(DLL) for converting a floating-point number to a
character string. It displays eight floating-point numbers
and eight conversions.

DLLFLOAT was built and tested under Microsoft(R)
Windows(TM) version 3.1.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The DLLSKEL sample can be downloaded from the
**** file 4-26.zip in library section number 4
****

DLLSKEL: Demonstrates Medium-Model DLL

DLLSKEL shows how to create a medium-model dynamic-link
library (DLL) and how to load it implicitly. The program
demonstrates C and Pascal calling conventions.

DLLSKEL was built and tested under Microsoft(R)
Windows(TM) version 3.1.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The FAULT sample can be downloaded from the
**** file 4-27.zip in library section number 4
****

FAULT: Demonstrates Exception and Fault Trapping

FAULT demonstrates a method for trapping divide-by-zero
exceptions and general protection (GP) faults in a retail
application. It also shows how to recover from these
problems using the Catch and Throw functions in
Microsoft(R) Windows(TM). Instead of forcing the user to
terminate, the application can quietly recover from the
problem and fail the operation, if at all possible. FAULT
is a companion program for the "Bulletproof Functions With
ToolHelper" technical article on the Microsoft Developer
Network CD.

The ability to trap exceptions gives an application
considerable power and responsibility. ToolHelper lets you
trap all exceptions, including Interrupt 3 (debug
breakpoints) and the CTRL+ALT+SYSRQ key sequence. Some
exception-handling techniques (for example, debugging
interrupts) should never be used in a retail product.
However, these techniques let you perform minor cleanup,
error logging, and similar tasks without user intervention
and without terminating the application in the debugging
version of your application.

FAULT was built and tested under Microsoft Windows version
3.1.

KEYWORDS: PR-CD2; InterruptRegister; InterruptUnRegister;
asm; assembler

=============================================================================

=============================================================================

****
**** The ISHANDLE sample can be downloaded from the
**** file 4-28.zip in library section number 4
****

HANDLE and ISHANDLE: Validate Global and Local Handles

This sample consists of two components:

>  ISHANDLE.DLL is a dynamic-link library (DLL) that
exports two functions, IsGlobalHandle and IsLocalHandle,
which validate global and local handles.

>  HANDLE.EXE is an application that tests these two
functions by linking into the DLL.

The IsLocalHandle and IsGlobalHandle functions in
ISHANDLE.DLL use a set of functions from TOOLHELP.DLL to
validate the given local or global handle. IsLocalHandle
uses the LocalFirst and LocalNext functions to walk the
local heap until the desired local handle is found.
Similarly, IsGlobalFunction uses the GlobalFirst and
GlobalNext functions to walk the global heap until the
desired global handle is found.

HANDLE demonstrates the IsLocalHandle and IsGlobalHandle
functions by passing good and bad handles to these
functions.

The following code shows how IsLocalHandle walks the local
heap and validates the given local handle, hLocalHandle.


/* Declare local variables. */
LOCALENTRY LEntry;

/* Allocate a buffer to do the local heap walk. */
bFound = FALSE;
LEntry.dwSize = sizeof(LOCALENTRY);

/* Loop through the local heap until hLocalHandle is
found. */
if (LocalFirst(&LEntry, wHeap))
{
do
{
if (LEntry.hHandle == hLocalHandle)
{
bFound = TRUE;
break;
}
} while (LocalNext(&LEntry));
}

if (bFound)
return hLocalHandle;
else
return NULL;

You can adopt this idea to walk the local/global heap and
obtain/store more information on a block of memory from
the LOCALENTRY and GLOBALENTRY structures. For example,
you can build a dynamic list that maintains information
about the heaps, or use the DLL to simulate the
functionality of the TOOLHELP ModuleFindHandle and
TaskFindHandle functions.

HANDLE requires Microsoft(R) Windows(TM) version 3.1 to
build, but has been compiled for 3.1 and 3.0
compatibility. TOOLHELP.DLL was not shipped with Windows
3.0; you must copy this library to the \WINDOWS\SYSTEM
directory to run HANDLE under 3.0.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The MULTAPP sample can be downloaded from the
**** file 4-29.zip in library section number 4
****

MULTAPP: Multi-Instance DLL with Separate Data

MULTAPP creates a multi-instance dynamic-link library
(DLL) that maintains separate data for each task that
links to it. A task is identified by the value of its
stack segment (SS). Data for each task is stored in a
block of memory obtained through GlobalAlloc. When a task
calls a function in the DLL, the DLL looks up the task in
its list and gets the segment (selector) of the global
memory block that contains the data for that task. The
segment address is then placed into the DS register. After
this point, all static data and the local heap are
specific to the task that called the DLL.

MULTAPP provides menu options for entering data into the
DLL's data segment, retrieving data from the DLL's data
segment, and filling the local heap with data items.

The first time a task calls into the DLL, a new block of
memory is allocated for the task's data. The initial
values for the static variables are copied into the block
and a local heap is initialized.

When a task that has called into the DLL shuts down, it
must call the UnregisterTask function. This function
removes the task from the DLL's list and frees the data
associated with the task. If the task does not call
UnregisterTask, another task with the same SS as the first
task might link to the DLL. Since the first task did not
unregister itself, the SS will be associated with a DS
that is no longer present, and will cause a UAE.

MULTAPP was built and tested under Microsoft(R)
Windows(TM) version 3.1.

KEYWORDS: PR-CD2; LocalReAlloc; LocalAlloc; LocalLock;
LocalUnLock; GlobalSize; GlobalAlloc; GlobalLock; _fmemcpy

=============================================================================

=============================================================================

****
**** The TERMWAIT sample can be downloaded from the
**** file 4-30.zip in library section number 4
****

TERMWAIT: Launches Child Task and Waits

TERMWAIT launches a child task and waits for it to
terminate before executing specific code. The program uses
TOOLHELP library functions for this purpose and launches
Notepad as an example.

TERMWAIT installs a notification callback function using
NotifyRegister before calling WinExec to launch the child
task. All system tasks call this notification function
before termination. The notification function calls
TaskFindHandle to obtain TASKENTRY information about the
terminating task and consequently determines if TERMWAIT
launched the terminating task.

TERMWAIT sets the bChildIsExecuting global variable to
TRUE when the child task is spawned and sets it to FALSE
after the child task has terminated. Any code that should
not be executed while the child is running can check the
value of bChildIsExecuting. Menu choices that may cause re-
entrancy problems during the wait should be grayed. The
AfterChildHasTerminated function contains code that can be
executed only after the child task has terminated.

If an application needs to keep track of a number of child
tasks, it can process both NFY_STARTTASK and NFY_ENDTASK
in the NotifyRegister callback function. GetCurrentTask
will return the handle of the task that called the
notification. This information can be managed by the
parent task. Although tasks cannot share the same handle,
task handles can be re-used. If one task terminates and
another one starts, the new task can have the same handle
as the task that just terminated. This is not a problem if
the parent task uses the NotifyRegister callback function
to detect when a task has terminated.

TERMWAIT was built and tested under Microsoft(R)
Windows(TM) version 3.1. TERMWAIT requires Windows 3.1 to
build, but has been compiled for 3.1 and 3.0
compatibility. TOOLHELP.DLL was not shipped with Windows
3.0; you must copy this library to the \WINDOWS\SYSTEM
directory to run TERMWAIT under 3.0.

KEYWORDS: PR-CD2; GetCurrentTask; NotifyUnRegister;
TaskFindHandle

=============================================================================

=============================================================================

****
**** The MIDIKEYB sample can be downloaded from the
**** file 4-31.zip in library section number 4
****

MIDIKEYB: Demonstrates the midiKeyB Control

MIDIKEYB is designed to show how to use midiKeyB, which is
a custom control that implements a musical instrument
digital interface (MIDI)-style keyboard. This keyboard is
not exactly the best keyboard for a jam session; don't
expect to hit a bunch of hemidemisemiquavers at correct
tempo.

The midiKeyB control responds to and sends short MIDI
messages. The right mouse button is used for "sticky keys"
and toggles the state appropriately.

For more information, see the function headers in the
source code.

MIDIKEYB was built and tested under Microsoft(R)
Windows(TM) version 3.1.

=============================================================================

=============================================================================

****
**** The ZYZGAUGE sample can be downloaded from the
**** file 4-32.zip in library section number 4
****

ZYZGAUGE: Demonstrates Progress Bar

ZYZGAUGE shows how to use the zYzGauge control. The Gas
Gauge Custom Control in the client window gives you a
progress bar class named zYzGauge. You can set the range,
position, font, color, orientation, and 3D effect of the
gauge by sending messages to the control.

For more information on using the control, please see the
header information in ZYZGAUGE.C.

ZYZGAUGE was built and tested under Microsoft(R)
Windows(TM) version 3.1.

=============================================================================

=============================================================================

****
**** The ALCKEY sample can be downloaded from the
**** file 4-33.zip in library section number 4
****

ALCKEY: Uses ALC Values to Filter Input

ALCKEY is a Microsoft(R) Windows(TM) for Pen Computing
program that shows how to use ALC values to specify how an
hedit (or bedit) control will filter its input.

ALC values define the types of values that a pen hedit or
bedit control will recognize. For example, ALC_NUMERIC
allows only numeric values to be recognized in a
particular control. Using ALC values allows you greater
freedom in customizing your application's response to ink.
Defining a small subset of ALC values for an edit control
increases the recognition of those values.

ALCKEY displays two edit controls: an hedit and a bedit.
You can select flags from the ALC dialog box for the hedit
control. The bedit control remains unchanged so you can
see the difference between the settings of the two
controls.

ALCKEY also demonstrates the use of the ShowKeyboard
function and shows the recommended way of interfacing to
the virtual keyboard through an owner-drawn "keyboard"
button. Notice that the virtual keyboard always stays on
top but never has the focus. The keyboard output is
directed to the last control that had the focus. ALCKEY
also demonstrates a way to ensure that only valid controls
get the focus. The virtual keyboard in Windows for Pen
Computing version 1.0 is not affected by the filtering
effects of ALC values. Only recognized ink is affected;
the keyboard does not involve inking so it bypasses this
step.

ALCKEY was built and tested under Microsoft Windows
version 3.1. The program requires PENWIN.DLL, which can be
found in both Microsoft Windows for Pen Computing and the
Microsoft Windows version 3.1 Software Development Kit
(SDK).

KEYWORDS: PR-CD2; LoadString; LoadBitmap;
GetSystemMetrics; CreateCompatibleDC; StretchBlt; _fmemcpy

=============================================================================

=============================================================================

****
**** The ANNOPRNT sample can be downloaded from the
**** file 4-34.zip in library section number 4
****

ANNOPRNT: Annotates and Prints Text and Ink

ANNOPRNT is a Microsoft(R) Windows(TM) for Pen Computing
program that demonstrates how to annotate a text file with
ink and output the annotated text to a printer.

The program demonstrates several techniques for printing
annotated text:

> Certain pen functions are more suitable for printer
output. For example, DrawPenData is more suitable than
RedisplayPenData, which depends on the video driver.

>  ANNOPRNT shows how to output different colors of ink,
so you can see the results of the color mapping on
specific printers (some colors do not show up on a
printer).

>  Another method involves printing the annotated text
file as a device-independent bitmap (DIB), thus allowing
the driver to do the color mapping instead of the graphics
device interface (GDI). Drivers typically map better to
gray scale, so you can use this technique if color is
important. The WINCAP sample application on the Microsoft
Developer Network CD demonstrates how to output DIBs to
printers.

Although ANNOPRNT was checked carefully for possible
printing problems, some printer drivers may cause errors.
If you experience problems running this program, contact
the Windows for Pen Computing support group on the
CompuServe(R) WINEXT forum, section 8 (the Pen Section).

ANNOPRNT was built and tested under Microsoft Windows
version 3.1. The program requires PENWIN.DLL, which can be
found in both Microsoft Windows for Pen Computing and the
Microsoft Windows version 3.1 Software Development Kit
(SDK).

KEYWORDS: PR-CD2; GetPenDataInfo; GetDeviceCaps;
CreatePen; DrawPenData; SetBkMode; SetMapMode;
SetWindowExt; SetViewportExt; PrintDlg; _lopen; _lread;
DestroyPenData; GetOpenFileName; IsPenEvent;
DuplicatePenData; CompactPenData; MetricScalePenData;
OffsetPenData; RedisplayPenData

=============================================================================

=============================================================================

****
**** The ANNOTATE sample can be downloaded from the
**** file 4-34.zip in library section number 4
****

ANNOTATE: Adds Handwriting to a Text File

ANNOTATE adds handwriting information to a text file. This
sample can serve as a starting point for writing pen-
centric annotation applications.

There are many issues involved in writing an application
that offers full-scale annotations: movement, saving ink
to a file, delayed recognition, and use of gestures. To
attach ink to a specified position of the text file
involves scrolling and repainting the ink in the
appropriate position. ANNOTATE demonstrates a scrolling
algorithm that scrolls the ink with the text file
appropriately. Other scrolling algorithms are also
possible. The RedisplayPenData function redisplays the
ink, and the DuplicatePenData function saves ink over the
life of the application.

ANNOTATE also demonstrates how to change ink color and
width dynamically.

ANNOTATE was built and tested under Microsoft(R)
Windows(TM) version 3.1. The program requires PENWIN.DLL,
which can be found in both Microsoft Windows for Pen
Computing and the Microsoft Windows version 3.1 Software
Development Kit (SDK).




=============================================================================

=============================================================================

****
**** The DYNBEDIT sample can be downloaded from the
**** file 4-36.zip in library section number 4
****

DYNBEDIT: Changes Edit Control to Bedit Control at Run
Time

DYNBEDIT shows how to change a normal edit control to a
bedit control at run time. This allows an application to
run unmodified in Microsoft(R) Windows(TM) for Pen
Computing or in the retail version of Windows.

DYNBEDIT requires PENWIN.DLL, which can be found in both
Microsoft Windows for Pen Computing and the Microsoft
Windows version 3.1 Software Development Kit (SDK).

By default, the Windows for Pen Computing system changes
an edit control to a hedit control at run time but lacks
the mechanism for changing an edit control to a bedit
control.

To perform this transition, the application must query the
information from the edit control, destroy the edit
control, and then call CreateWindow to make the new bedit
control. However, this technique causes problems if you
use a font other than the system font in a dialog box. For
example, the font statement FONT 8,"Helv" will cause the
combs of the bedit control to appear below the bottom
border of the control because Windows for Pen Computing
calculates the size of the combs in the system font. To
avoid this problem, the application must reduce the size
of the GUIDE structure in the RC structure for the new
control. The system will pick a new font that matches the
new GUIDE size. For more information, please see the
README.TXT file.

DYNBEDIT was built and tested under Microsoft Windows
version 3.1.



=============================================================================

=============================================================================

****
**** The GRID sample can be downloaded from the
**** file 4-37.zip in library section number 4
****

GRID: Demonstrates Circle Gestures and Much More

GRID is a sample pen application that demonstrates the
following features:

>  How to change the shape of a mouse cursor when the
state of the system changes

>  How to process the REC_POINTEREVENT return code from
the Recognize function to distinguish between a Tap and a
TapNHold

>  How to support a circle gesture

>  How to cut and paste ink to the Clipboard,

>  How to operate the correct writing dialog

>  How to use the recognition termination condition of
PCM_RECTBOUND to allow a user to enter information quickly

GRID was built and tested under Microsoft(R) Windows(TM)
version 3.1. The program requires Microsoft Windows for
Pen Computing.



=============================================================================

=============================================================================

****
**** The HOTSPOTS sample can be downloaded from the
**** file 4-38.zip in library section number 4
****

HOTSPOTS: Reconizes Hotspots Associated with Gestures

HOTSPOTS is a pen application that helps developers
recognize hotspots associated with gestures. When the user
draws a gesture, HOTSPOTS redisplays the ink using a red
pen. If the gesture has a hotspot, the hotspot is circled
with a small black dot. If the input was not a gesture, it
is drawn in black.

HOTSPOTS requires PENWIN.DLL, which can be found in both
Microsoft(R) Windows(TM) for Pen Computing and the
Microsoft Windows version 3.1 Software Development Kit
(SDK).

HOTSPOTS was built and tested under Microsoft Windows
version 3.1. The program is designed to work with
Microsoft Windows for Pen Computing.



=============================================================================

=============================================================================

****
**** The PARSER sample can be downloaded from the
**** file 4-39.zip in library section number 4
****

Parser: Maps Raw Data to Recognized Characters

Parser is a Microsoft(R) Windows(TM) for Pen Computing
program that demonstrates how to parse the symbol element
(SYE) array of the symbol graph (SYG) structure using
symbol values (SYVs) and symbol correspondence (SYC)
arrays where appropriate. The purpose of the program is to
determine the strokes associated with the recognized
characters.

Parser is designed around three main components of Windows
for Pen Computing: the "best guess" array of SYVs, the
HPENDATA structure, and the SYE in the SYG structure.

During a single recognition session, the "ink" (vector-
based x,y coordinates of the user's input) is stored in
the HPENDATA structure of the RCRESULT structure. The
lpsyv field of the RCRESULT structure also contains the
"best guess" array of symbol values that the system thinks
the ink represents. This array can be used in conjunction
with the SYE array and the SYC structure to isolate
individual characters in the ink and associate them with
their corresponding ink strokes (or partial strokes) in
the HPENDATA structure. SYGs, SYVs, SYEs, and SYC
structures are typically the most difficult and confusing
components of the pen architecture. These structures are
interrelated, and it is necessary to parse one array while
another array is being similarly parsed. The Parser
program provides a clear and fairly simple demonstration
of the parsing mechanism. For more information on SYGs,
SYVs, SYEs, and SYCs, see the Windows for Pen Computing
online help system or the Windows version 3.1 Software
Development Kit (SDK) "Microsoft Windows for Pen
Computing: Programmer's Reference" manual.

Parser has the same architecture as the View sample
application on the Microsoft Developer Network CD. View
demonstrates slow drawing, automatic positioning of text
strings returned as the "best guess" from the recognizer,
and dynamically sizing the text string with a matching
TrueType(R) font. The View sample returns a TrueType text
string based on the entire HPENDATA structure, and uses
the bounding rectangle of the entire ink data to size the
font for the string. Parser, on the other hand, walks the
SYE array of the SYG structure looking for the iSyc values
so the SYC structure can be used to find the individual
data strokes for the characters in the HPENDATA structure.
For example, the letter "t" will typically consist of two
strokes, although the strokes are not necessarily
sequential in the HPENDATA structure--for example, the
user can cross the "t" after writing other characters. The
SYC references both strokes and gives an index into the
HPENDATA to retrieve them.

Once Parser associates the "best guess" array of symbol
values to the raw data in the HPENDATA structure, it uses
the raw data points to determine the size of the user's
input, and selects a TrueType font. The size and position
of each individual character the user enters is
independent of all other characters and is displayed as
such.

Parser currently displays a maximum of 10 characters (as
text), regardless of how many characters the user has
entered. You can remove this limitation by adjusting the
MAXCHARMAP value in the CONVERT.H file. When you select
DisplayAsText, Parser displays the SYE array in the upper-
left corner of the client area so the user can see the
results of the recognition process.

Parser was built and tested under Microsoft Windows
version 3.1. The program requires PENWIN.DLL, which can be
found in both Microsoft Windows for Pen Computing and the
Microsoft Windows version 3.1 SDK. Parser also requires
the TrueType Arial font.

KEYWORDS: PR-CD2; DuplicatePenData; MetricScalePenData;
FIsGesture; _fstrnlen; _fstrncpy; OffsetPenData;
GetPenDataStroke; SymbolToCharacter; FIsAppGesture;
RedisplayPenData; GetPointsFromPenData; GetPenDataInfo;
BeginEnumStrokes; CreatePenData; AddPointsPenData;
_fmemcpy; EndEnumStrokes; DestroyPenData; IsPenEvent;
InitRC; Recognize

=============================================================================

=============================================================================

****
**** The PRESSURE sample can be downloaded from the
**** file 4-40.zip in library section number 4
****

PRESSURE: Captures Pressure Information

PRESSURE demonstrates one way of capturing pressure
information from Microsoft(R) Windows(TM) for Pen
Computing using the GetPenHwEventData function.

PRESSURE requires PENWIN.DLL, which can be found in both
Microsoft Windows for Pen Computing and the Microsoft
Windows version 3.1 Software Development Kit (SDK).
PRESSURE also works on a tablet that has pressure-sensing
capabilities.

PRESSURE was built and tested under Microsoft Windows
version 3.1.



=============================================================================

=============================================================================

****
**** The RCDUMP sample can be downloaded from the
**** file 4-41.zip in library section number 4
****

RCDUMP: Displays RCRESULT Structure

The RCDUMP sample program displays the entire RCRESULT
structure and shows the cause and effect of different RC
options in real time.

Developers who are unfamiliar with the Microsoft(R)
Windows(TM) for Pen Computing system can use RCDUMP while
reading the pen documentation to understand the actions of
different flags and settings.

Developers who are implementing recognizers and
dictionaries for Windows for Pen Computing can use RCDUMP
to view and test different RC settings in their system
components. RCDUMP allows you to change RC settings and
immediately see the effects of the change.

For more information on RCDUMP, please see the RCDUMP.DOC
file.

RCDUMP was built and tested under Microsoft Windows
verison 3.1.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The VIEW sample can be downloaded from the
**** file 4-42.zip in library section number 4
****

View : Draws Ink at a Slower Rate

View is a Microsoft(R) Windows(TM) for Pen Computing
program that demonstrates the following:

>  Displaying ink using the RedisplayPenData function.

>  Displaying the "best guess" in text from the
recognizer.

>  Using TrueType(R) fonts to mimic the height of the raw
ink text.

>  Parsing the individual ink data points and doing a
"slow draw" of the ink.

View demonstrates a conversion algorithm that you can use
to convert raw ink into recognized values. These values
can then be converted and displayed as text on a device
context (DC) in a TrueType font so that the font string
mimics the raw ink string height. See the Windows version
3.1 Software Development Kit (SDK) "Microsoft Windows for
Pen Computing: Programmer's Reference" manual for more
information on recognition results.

View also shows how to use a timer callback function to
walk through the individual stroke points and draw them
one by one. A timer allows you to slow down the speed at
which the ink is redrawn to observe how the user draws the
ink.

View was built and tested under Microsoft Windows version
3.1. The program requires PENWIN.DLL, which can be found
in both Microsoft Windows for Pen Computing and the
Microsoft Windows version 3.1 SDK. View also requires the
TrueType Arial font.

KEYWORDS: PR-CD2; SymbolToCharacter; _fstrncpy;
IsPenEvent; DestroyPenData; Recognize; DuplicatePenData;
MetricScalePenData; OffsetPenData; GetPenDataInfo;
BeginEnumStrokes; GetPenDataStrokes; GetPointsFromPenData;
EndEnumStrokes

=============================================================================

=============================================================================

****
**** The HEALTH sample can be downloaded from the
**** file 4-43.zip in library section number 4
****

HEALTH: Visual Basic(TM) 1.0 Pen Healthcare Application

HEALTH contains seven forms for admitting and diagnosing a
patient in a healthcare facility. This program is fairly
large and unoptimized, so load times are significant. Tap
firmly on the buttons for Next Page, Previous Page, and so
on, and then wait as HEALTH loads each form.

>  The first form is a Patient Identification form. To
complete this form, enter numbers in the bedit field, tap
the button, then tap the appropriate Gender radio button.
Do not tap the Enable Entry Checking check box in the
lower part of the screen--this option opens a smart form
that won't let you move to the next screen until all
fields are filled out.

>  The second form is fairly straightforward. Note that if
you tap the icon, it will reformat and lock that field.
For example, after entering the date, tap the icon next to
it to format the date and lock that field.

>  The third form, In Case of Emergency Notify, contains
an hedit field for medical diagnosis. You can write
anything you want in this field, but print neatly. The
application will try to recognize whatever you write.

>  The fourth form, Physical, contains diagrams of the
body. You can draw on these diagrams to diagnose or
highlight any problems. This screen takes some time to
load, so tap the Next Page icon quickly. The ink display
rate is good; hold the pen down on the screen for a
second, and then write as quickly as you like. You can tap
the Lock icon once to lock the ink, and a second time to
clear the screen.

> The fifth form, Clinical Assessment, contains multiple
forms that you can fill out to note allergies, hearing and
eyesight limitations, and so on. To view all forms at
once, choose Arrange from the top part of the screen.
However, having many screens on display can intimidate a
new user, so we suggest that you fill out only the first
form. For example:

1.  Tap Hearing.

2.  Tap Normal Left.

3.  Tap Impaired Right.

4.  Tap Vision.

5.  Tap Impaired.

6.  Tap Glasses.

7.  Tap Far-sighted.

8.  Tap Next Page to move to the next form. Next Page
appears as text (not as a button) in the upper-right
corner of the screen.

>  The sixth form is a diagnosis screen. Use the scroll
bars to scroll through the potential diagnoses (some of
them are rather humorous), and select the most appropriate
one. This is the last form, so tap the Exit button
(represented by an open door) at the bottom of the screen
to close the application.

> The seventh form is brought up every time you tap the
open door icon. The menus allow you to save your work,
view the different screens that you have entered, or exit
the application.

You move from form to form using the Next Page or Previous
Page buttons at the bottom of the screen. You can close
the application or skip pages at any point by tapping the
half-open door icon at the bottom of the screen.

HEALTH was built and tested under Microsoft(R) Windows(TM)
version 3.1 and Visual Basic version 1.0. The program
requires PENWIN.DLL, which can be found in both Microsoft
Windows for Pen Computing and the Microsoft Windows
version 3.1 Software Development Kit (SDK).

KEYWORDS: PR-CD2; VB

=============================================================================

=============================================================================

****
**** The INSURE2 sample can be downloaded from the
**** file 4-44.zip in library section number 4
****

INSURE2: Visual Basic(TM) 1.0 Pen Insurance Application

INSURE2 is a Visual Basic pen program that displays an
insurance policy application for insurance agents to fill
out.

INSURE2 demonstrates the functionality of Visual Basic
controls for Microsoft(R) Windows(TM) for Pen Computing.
It uses bedit fields, hedit fields (with DelayRecog on and
off), and an array of "point-and-shoot" fields (check
boxes, option buttons, and so on). INSURE2 is very
flexible; you can go back and forth between edit screens
to update information.

On the main form, the Current Occupation input area is
ink, so you can write in cursive. To access the list
boxes, just tap the associated buttons.

The Load and Save Form buttons are not functional, but
tapping these does not cause any error messages. Cick the
action buttons at the bottom of each form to move back and
forth between forms. To exit the application, tap the
Report button and select the Exit application button at
the bottom of the screen.

INSURE2 was built and tested under Microsoft Windows
version 3.1 and Visual Basic version 1.0. The program
requires PENWIN.DLL, which can be found in both Microsoft
Windows for Pen Computing and the Microsoft Windows
version 3.1 Software Development Kit (SDK).

KEYWORDS: PR-CD2; VB

=============================================================================

=============================================================================

****
**** The LOANAPP sample can be downloaded from the
**** file 4-45.zip in library section number 4
****

LOANAPP: Visual Basic(TM) 1.0 Pen Loan Application

LOANAPP is a Microsoft(R) Windows(TM) for Pen Computing
application that was developed using Visual Basic with
Professional Toolkit. LOANAPP lets you fill out a loan
application using bedit fields, check boxes, and hedit
fields.

To input information, double-click a field to bring up
that section's input screen and write in the information.
To change or reenter information in an input field, double-
click the input field. To move from screen to screen, tap
the buttons at the top of the screen. Select Save from the
File menu to save data. Select Load from the File menu to
load in a demo file that you might have created earlier.

There is some really good editing going on in LOANAPP. For
example, no matter where you write in the bedit fields,
your entry appears left justified in the final form. The
application converts the State field entry to uppercase,
regardless of how you entered it.

LOANAPP was developed for the mobile environment, which
requires large input fields and a clear indication of
where the user should enter information. In LOANAPP, input
fields appear on separate screens, background colors are
blue/black, and input fields are white.

On the last screen, double click the Date field at the
bottom of the screen to display the current date. LOANAPP
reads the time setting from your pentop. Use the buttons
at the top of each form to delete either all fields in the
current screen or all fields in all screens. Double-click
the Erase Signature buttons to clear Signature boxes. To
exit the application, choose Exit from the File menu.

LOANAPP was built and tested under Microsoft Windows
version 3.1 and Visual Basic version 1.0. The program
requires PENWIN.DLL, which can be found in both Microsoft
Windows for Pen Computing and the Microsoft Windows
version 3.1 Software Development Kit (SDK).

KEYWORDS: PR-CD2; VB

=============================================================================

=============================================================================

****
**** The RECEIPT sample can be downloaded from the
**** file 4-46.zip in library section number 4
****

RECEIPT: Visual Basic(TM) 1.0 Pen Order Application

RECEIPT is a Microsoft(R) Windows(TM) for Pen Computing
application that was developed using Visual Basic with
Professional Toolkit. RECEIPT lets you fill out an order
for Microsoft products, do a credit check, and pay for the
product.

RECEIPT is a fun application that the Visual Basic group
at Microsoft put together for the Windows version 3.1
announcement. It mirrors the process Microsoft uses to
take product orders and highlights the importance of
connectivity.

You must follow the demo outline below to see the complete
functionality of the application:

1.  Write "Mike Smith" in the Name field. If you get a
recognition error, write over the unrecognized character.

2.  Tap the Look-Up button in the upper-right corner of
the screen.

3.  Tap the product list box and select a few products.
Tap again to add products to the table and order totals
below.

4.  Tap the Place Order button in the upper-right corner
of the screen.

5.  Erase "Mike Smith" using the scratch out gesture, and
write in a new name. If you get a recognition error, write
over the character that was misrecognized.

6.  Tap the Check Credit button in the lower part of the
screen.

7.  Tap the Bill Me Later option button and sign for the
order.

8.  Tap the Place Order button.

9.  Close the application by double-tapping the Windows
icon in the right half of the screen.

RECEIPT was built and tested under Microsoft Windows
version 3.1 and Visual Basic version 1.0. The program
requires PENWIN.DLL, which can be found in both Microsoft
Windows for Pen Computing and the Microsoft Windows
version 3.1 Software Development Kit (SDK).

KEYWORDS: PR-CD2; VB

=============================================================================

=============================================================================

****
**** The SALEANAL sample can be downloaded from the
**** file 4-47.zip in library section number 4
****

SALEANAL: Visual Basic(TM) Pen Forecast Tracking
Application

SALEANAL is a Microsoft(R) Windows(TM) for Pen Computing
application that was developed using Visual Basic with
Professional Toolkit. The application implements a
salesperson's performance sheet and includes built-in
calculations, note areas to capture ink, and links to
Microsoft Excel for charting capabilities.

SALEANAL consists of three main forms:

>  The first form contains the date, sales representative
name, and territory fields, which are used as indexes into
a database. The available sales representatives and
territories are stored in a drop-down list box. You can
add new names and territories to this list.

>  If SALEANAL finds information in the database
pertaining to the selected date, sales representative, and
territory, it displays a Revenue and Expense Report form
with this information. If it does not find any
information, it displays the forecast for the current
month and for the next month, but does not show actual
figures. You can also enter notes or view a Year-to-Date
Profit chart in Microsoft Excel.

>  The third form displays information on days worked,
calls taken, new accounts gained, and total accounts
gained. You can also enter notes or view a Year-to-Date
Profit chart in Microsoft Excel. This chart shows how an
account might leverage the 5,000+ Windows-based
applications to produce a chart that highlights a sales
representative's performance.

If Microsoft Excel is not installed on your machine, tap
the chart icon in the third screen. This button launches
Microsoft Excel and automatically creates a chart.

You can access the Notes screen from the second or third
form. This screen lets you enter notes for the form. Notes
are maintained while you view or modify the information
for a particular date, sales representative, and
territory, but are lost when you return to the first
screen or exit the application.

SALEANAL was built and tested under Microsoft Windows
version 3.1 and Visual Basic version 1.0. The program
requires PENWIN.DLL, which can be found in both Microsoft
Windows for Pen Computing and the Microsoft Windows
version 3.1 Software Development Kit (SDK).

KEYWORDS: PR-CD2; VB

=============================================================================

=============================================================================

****
**** The VBPRINT sample can be downloaded from the
**** file 4-62.zip in library section number 4
****

VBPRINT: Demonstrates Printing in Visual Basic 2.0

VBPRINT is a dynamic-link library (DLL) that contains
printing functions for Visual Basic(TM) version 2.0. These
functions are defined in the VBPRINT.TXT file.

The print control application, TESTAPP, demonstrates the
printing functions in VBPRINT.DLL. This application
contains buttons to print graphics, text, and column
output.

VBPRINT and TESTAPP were built using Microsoft Visual
Basic version 2.0.

KEYWORDS: CD3

=============================================================================

=============================================================================

****
**** The COOLCOLR sample can be downloaded from the
**** file 4-48.zip in library section number 4
****

COOLCOLR: Changes System Colors

COOLCOLR is a Control Panel extension that lets you change
your system colors by dragging and dropping color
selections. To install COOLCOLR, copy the COOLCOLR.CPL
file to your Microsoft(R) Windows(TM) SYSTEM directory.
The next time you run Control Panel, the System Color
Dropper icon will appear in the Control Panel window.

Start COOLCOLR by double-clicking the System Color Dropper
icon. Click a basic color from the System Color Dropper
window, drag it to a menu, scroll bar, or any other system
area on the screen, and drop it. The system color is
updated immediately. Choose Cancel from the System Color
Dropper window to restore your original settings, or OK to
save your color changes to the WIN.INI file.

COOLCOLR uses a modified version of the ChooseColor common
dialog box, a custom template, and a hook function.

COOLCOLR was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The DYNDLG sample can be downloaded from the
**** file 4-49.zip in library section number 4
****

DYNDLG: Implements Options Dialog Box

DYNDLG implements the Options dialog box that users can
access from the Tools menu in Word for Windows(TM) version
2.0. It creates an owner-drawn list box of icons
representing option categories, and depending on the
category icon selected, changes the options on the right
side of the dialog box.

DYNDLG was built and tested under Microsoft(R) Windows
version 3.1.

KEYWORDS: PR-CD2; DialogBox; SendDlgItemMessage; DrawIcon;
GetTextMetrics; DrawText; AddIconToListBox;
ShowAllControls; GetSystemMetrics; GetSysColor; PatBlt;
EndDialog

=============================================================================

=============================================================================

****
**** The EXEVIEW sample can be downloaded from the
**** file 4-50.zip in library section number 4
****

EXEVIEW: Extracts and Decodes Information from Executable
Files

EXEVIEW demonstrates how to extract and decode resources
and tables from executable files or library files. (FONTS
and DRVs qualify as dynamic link libraries [DLLs]).

Applications often wish to extract information from an
executable file without loading the application itself.
For example, the Microsoft(R) Windows(TM) Program Manager
extracts an icon from an .EXE file to represent an
application. There are many other resources and tables in
an .EXE file (or in a DLL) that may be useful to certain
applications.

EXEVIEW uses the old and new header formats, which are
documented in the "MS-DOS Encyclopedia" (Microsoft Press,
1988). EXEVIEW loads these headers and the associated
tables that these headers point at, including the entry
table, the segment table, the resource table, the resident
and non-resident name tables, and the imported name
tables. EXEVIEW also loads the resources from the resource
table. If a resource can be displayed graphically (for
example, icons, cursors, bitmaps, menus), it is. Resources
for string tables and directories (for example, icons,
cursors, fonts) are listed in a text format.

For more information on file and resource formats, see the
Microsoft Systems Journal, Vol. 6, No. 5
(September/October 1991) or the "MS-DOS Encyclopedia"
(Microsoft Press, 1988).

EXEVIEW was built and tested under Microsoft Windows
version 3.1.

=============================================================================

=============================================================================

****
**** The HITTEST sample can be downloaded from the
**** file 4-51.zip in library section number 4
****

HITTEST: Displays Dialog Box for Icon

HITTEST lets you double-click an icon to display a dialog
box associated with the icon. It is similar to the Control
Panel, which runs an applet associated with an icon.

HITTEST was built and tested under Microsoft(R)
Windows(TM) version 3.1.

KEYWORDS: PR-CD2; SetDlgItemText; EndDialog;
CreateCompatibleDC; CreateBitmap; GetObject; SelectObject;
SetOKColor; BitBlt; GetStockObject; GetSystemMetrics;
LoadIcon; SetTextColor; SetBkColor; DrawText;
DrawItemText; DialogBoxParam; BitBlt

=============================================================================

=============================================================================

****
**** The HOTKEYED sample can be downloaded from the
**** file 4-52.zip in library section number 4
****

HotKeyed: Implements an Edit Control for Shortcut Keys

HotKeyed implements a shortcut key (hot key) edit control.
The application displays a dialog box that allows the user
to specify a shortcut key. This dialog box uses a
subclassed edit control to display the name of the
shortcut key the user enters.

The edit control checks the shortcut key to prevent the
user from specifying invalid keys. HotKeyed uses the
GetKeyNameText function to retrieve the key name.

A shortcut key must have an ALT or/and CTRL modifier. The
SHIFT modifier can also be added to the ALT or CTRL
sequence. To erase a key combination from the edit
control, use BACKSPACE or enter another key combination.
The ESC, ENTER, TAB, SPACEBAR, and PRINT SCREEN keys are
not allowed.

If the user enters a valid shortcut key, HotKeyed lets the
user install the key. HotKeyed uses the SetWindowsHookEx
hook function available in Microsoft(R) Windows(TM)
version 3.1 to install a task-specific keyboard hook. The
user can remove the shortcut key by selecting a menu
option or by exiting the application.

When the shortcut key is installed, HotKeyed flashes the
main window's title bar to indicate that a hot key has
been installed. The title bar continues to flash until the
shortcut key is removed. When the user presses the
shortcut key, HotKeyed toggles the main window's
background color.

HotKeyed was built and tested under Microsoft Windows
version 3.1, and requires this version of the operating
system.

KEYWORDS: PR-CD2; CreateSolidBrush; SetClassWord;
DialogBox; SetWindowLong; GetDlgItem; GetWindowText;
GetKeyState; SetTimer; KillTimer

=============================================================================

=============================================================================

****
**** The MDIDLG sample can be downloaded from the
**** file 4-53.zip in library section number 4
****

MDIDLG: Demonstrates MDI Dialog Box

Revised: November 24, 1992

MDIDLG demonstrates a multiple document interface (MDI)
dialog box that contains a combo box, an edit control, and
a list box. To see the dialog box, select New from the
File menu.

MDIDLG was built and tested under Microsoft(R) Windows(TM)
version 3.1.



=============================================================================

=============================================================================

****
**** The SIGNON sample can be downloaded from the
**** file 4-54.zip in library section number 4
****

SIGNON: Creates Sign-On Screen

Many companies like to display a sign-on screen while
their application is loading and initializing. When the
user performs some action indicating that he or she is
ready to begin using the application, the sign-on screen
disappears and the application proceeds as normal.

SIGNON is implemented with a modeless dialog box and some
extra processing in the main message loop. After the main
window is created and displayed, a modeless dialog
(usually containing the company name and copyright
information) appears in the main window. The main message
loop then watches for any action (for example, mouse
clicks, keystrokes, and menu accesses) indicating that the
user is ready to work. You can also create a timer to
remove the sign-on screen after a certain amount of time
(say, 5 seconds).

SIGNON was built and tested under Microsoft(R) Windows(TM)
version 3.1, but will also run under Windows version 3.0.

KEYWORDS: PR-CD2

=============================================================================

=============================================================================

****
**** The SYSPARAM sample can be downloaded from the
**** file 4-55.zip in library section number 4
****

SYSPARAM: Demonstrates the SystemParametersInfo Function

SYSPARAM uses the SystemParametersInfo function to display
and modify systemwide parameters.

SystemParametersInfo is a new function in the Microsoft(R)
Window(TM) version 3.1 Software Development Kit (SDK) that
lets you query or change most of the systemwide settings--
everything from the wallpaper on the desktop to the width
of window borders. SYSPARAM displays the systemwide
parameters and their current values in the client area.
You can choose options from the Set Params menu to change
these settings.

WARNING:  This sample modifies the WIN.INI file. Please
remember any changes you make to the system parameters so
you can reset them to their original values.

SYSPARAM was built and tested under Microsoft Windows
version 3.1.

KEYWORDS: icon spacing; language driver; screen saver;
keyboard speed; grid granularity; wallpaper; beep; border
width; menu drop

=============================================================================

