Arawak OS/2 Shareware/PAKLED.ISO/docs/edm/edmi2-7.inf

OS/2 Help File | 1994-07-10 | 235.2 KB | 1,801 lines

ΓòÉΓòÉΓòÉ 1. July 1994 Title Page ΓòÉΓòÉΓòÉ

                                      EDM/2

                  The Electronic Developer's Magazine for OS/2

                   Portions copyright (c) by Larry Salomon Jr.
                                Volume 2, issue 7

Copyright Notice and Other Stuff

The Editor-in-Chief of this electronic magazine is Larry Salomon, Jr.

Portions of EDM/2 are copyrighted by the editors.  This publication may be
freely distributed in electronic form provided that all parts are present in
their original unmodified form.  A reasonable fee may be charged for the
physical act of distribution; no fee may be charged for the publication itself.

All articles are copyrighted by their authors. No part of any article may be
reproduced without permission from the original author.

Neither this publication nor the editors are affiliated with International
Business Machines Corporation.

OS/2 is a registered trademark of International Business Machines Corporation.
Other trademarks are property of their respective owners.  Any mention of a
product in this publication does not constitute an endorsement or affiliation
unless specifically stated in the text.

Administrivia

Another month gone by; this month, I decided to incorporate more changes
suggested by Carsten (of which some were forwarded from readers).  Some of them
are listed below:

o The title page was rearranged somewhat.
o All articles and columns were moved to the top, instead of buried underneath
  another heading.
o Icons are now attached to most, if not all, pages of articles, columns, and
  other miscellaneous panels.

There are a couple of others, but I will let you find them.

And The Winner of the Most Forgetful Award Is...

me, obviously.  Not surprisingly, last month I lost the rdc.cmd file which was
to be included in the article Resources and Decompiling Them; it has been
included this month.

PC Expo Came and Went

PC Expo was enjoyable, even though I was there for Thursday only.  After three
years, I was finally allowed to peek behind the scenes at the IBM booth with
the animated character.  You know the one; he says the funniest one-liners and
usually makes a joke about Microsoft (which invariably results in a phone call
from one of that company's lawyers about libel) before the end of the show.
I've been trying to get a peek at how it was done for three years at least.
Now, I can die a happy man.  <grin>

Seriously, it was fun.  IBM was showing off these new 21 inch monitors (which
haven't been approved by the FCC), as well as the Power PCs running AIX and
OSF1.  I managed to hijack the IBM C-Set++ booth to give away five copies of my
book.  The Developer's Connection volume 4 is shipping as I write this and it
does contain some goodies; watch your mail!  Finally, I finagled a copy of the
OS/2-in-4M beta on CD-ROM but haven't gotten around to installing it.  The
kiosk of this at the Expo had an impressive demonstration running on a ThinkPad
with 4M and running either Word for Windows or Excel (cannot remember which),
Klondike Solitare (OS/2 version), and the Clock, and response was quite snappy.

Next Month...?

I will be taking a week for vacation this month and might decide to skip next
month's issue since everyone else seems to be enjoying their summer too. <grin>
There is a chance that I will still put out an August issue (flood me with
articles - hint hint - and the probably increases likewise), but I won't know
until I return.

Coming Soon

At work, I have had a need to develop a limited subset of the PM API for VIO
applications.  While the limitations to using it are many, the implementation
of the VIOWIN library is very interesting because it gives one an insight into
the implementation issues that the original PM developers had to face.  I
intend to discuss the library in-depth in a future issue, but cannot commit to
a specific issue.  Watch this space.

Title Page - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 2. Visual REXX Faceoff - Part 2 ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 2.1. Introduction ΓòÉΓòÉΓòÉ

Visual REXX Faceoff - Part 2

Written by Gordon Zeglinski

Introduction

This issue sees the second part of the Visual REXX Faceoff.  We start by
looking at VisPro REXX/Bronze Edition version 2.0 by Hockware and then compare
its features to that of VX-REXX.  The Bronze Edition is an entry level low cost
visual REXX product.  It is not a full blown environment like the VisPro REXX
Gold Edition or VX-REXX.

VisPro ships on a single floppy disk and comes with a 300+ page manual.

Visual REXX Faceoff (Part 2) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 2.2. Installation ΓòÉΓòÉΓòÉ

Installation

The VisPro REXX (VisPro for short) installation went smoothly.  Just pop in the
disk, set up the install path, wait a while, reboot, and it's ready to use.
Well, almost; do not try to second guess the instructions about installing the
Resource Compiler and LINK386 by using Selective Install. These two program
must be installed in the \OS2 directory on the boot drive (this was found out
the hard way).

When done, you will see the following folder on the desktop.

Figure 1. Installation Folder

Visual REXX Faceoff (Part 2) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 2.3. Look and Feel ΓòÉΓòÉΓòÉ

Look and Feel

In VisPro, the window you are working on (the form) is integrated with the
editing tools window as shown in figure 2. This is called the "layout view" in
VisPro.

Figure 2.  User Interface

In addition to the layout view, the forms have settings, list and event views.
The list view displays all the controls in the form, and their basic
characteristics.  The event view displays the controls and the events they
respond to.  Figure 3 shows the events view.

Figure 3.  Events View

VisPro uses WPS objects to represent projects.  It uses project folders and
"forms" to represent an application.  The project folder is simply a directory
where the project file are stored.  Forms represent windows in an application.
There are two types of forms:  the main form and sub forms.  Each application
must have a main form.  It can have zero, one or more sub-forms that represent
different windows.  Figure 4 shows the project folder.

Figure 4.  Project Folder

Like VX-REXX (see last issue for details), VisPro mimics the feel of the WPS.
Thus, getting used to the environment shouldn't take too long.  The reference
section of the manual is well-written.  You can search for a function by what
it does in addition to searching by its name.  This is really nice if you are a
fan of paper.  However, VisPro also has drag and drop coding and code insertion
abilities.  Figure 5 shows the edit window, with the code insertion menus open.

Figure 5.  Edit Window

Like the WPS, the settings for the forum and controls are presented in a
notebook.  Figure 6 shows the settings window for the main form.  Each control
has similar settings windows, with pages added or subtracted as needed to deal
with object specific properties.

Figure 6.  Properties Notebook

Visual REXX Faceoff (Part 2) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 2.4. Feature Comparison ΓòÉΓòÉΓòÉ

Feature Comparison

The following table will compare the features in VX-REXX Gold to those in
VisPro REXX Bronze.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéFeature                  ΓöéVX-REXX   ΓöéVisPro REXX Bronze  Γöé
Γöé                         ΓöéGold      Γöé                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéControl Windows          Γöé          Γöé                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéStatic Text              ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéGroup Box                ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéButton                   ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéRadio Button             ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéCheck Box                ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéPicture Button           ΓöéYes       ΓöéNo                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéPicture Radio Button     ΓöéYes       ΓöéNo                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéPicture Box              ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéList Box                 ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéCombination Box          ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDrop Down List           ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéEntry Field              ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéMulti Line Entry Field   ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéValue Set                ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéSlider                   ΓöéYes       ΓöéNo                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéSpin Button              ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéNotebook                 ΓöéYes       ΓöéNo                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéContainer                ΓöéYes       ΓöéNo                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéFree Form                ΓöéNo        ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéMenus                    ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéHelp Support             ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDDE                      ΓöéYes       ΓöéNo                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéTimer                    ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéThreads                  ΓöéYes       ΓöéNo (1)              Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDrag and Drop            ΓöéYes (2)   ΓöéNo                  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéQ+E support              ΓöéYes       ΓöéYes                 Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéISV extendible           ΓöéIn Beta   ΓöéYes                 Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

(1) Threads in REXX are not the same as threads in C. Global data is not
automatically shared in REXX.  There are several freeware and shareware REXX
libraries that will allow you to have multithreaded REXX progams.

(2) In container controls only

Keep in mind that when comparing these two visual REXX packages, the VisPro
package reviewed here is a low-cost, entry-level package.

Visual REXX Faceoff (Part 2) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 2.5. Wrapping Things Up ΓòÉΓòÉΓòÉ

Wrapping Things Up

The two visual REXX packages looked at here have much in common.  The biggest
difference between the two is the interface.  One other difference worth
mentioning is that VisPro REXX has a smaller runtime DLL (about 100 Kb) than
VX-REXX (about 740Kb).  This may be an important factor if you are thinking
about using a visual REXX to write a part of your application.

Both products have excellent support, through Compuserve, Internet, fax and
voice calls.  If you are looking for a low-cost, easy-to-use visual REXX
package, then VisPro REXX Bronze is the package for you.  If you want a little
more power, VX-REXX or VisPro REXX Gold will fit your needs nicely. With out
actually seeing the VisPro REXX Gold Edition myself, I can't definitively say
if it's database extensions are as good as they are rumored to be.  Hopefully,
if the future, we'll be able to look at the Gold edition as well.  Until then,
if you are looking for a package to work on database front ends, you should
find some literature on VisPro REXX Gold.

Visual REXX Faceoff (Part 2) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 3. Sprites and Animation - Part 3 ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 3.1. Introduction ΓòÉΓòÉΓòÉ

Sprites and Animation - Part 3

Written by Larry Salomon, Jr.

Introduction

In the final part of this series, we will wrap things up by looking at how
I495.EXE was built.  This will hopefully get you on your way to using animation
within your own applications, although it should be noted that no article or
series of articles will ever be able to give an exhaustive treatment of this
topic.  And when there are applications like Autodesk and Renderman available
(albeit expensive), hard-coded animations are rare.

Sprites and Animation (Part 3) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 3.2. Capabilities ΓòÉΓòÉΓòÉ

Capabilities

Before we can begin designing, we have to know what it is that we are designing
- what will the application do, how much of the behavior can be controlled by
the user, etc.  Fortunately, I495.EXE allows for little control by the user, so
the majority of the application is deterministic, i.e. we can predict what will
happen with high accuracy (this statement is a bit inaccurate depending on how
it is interpreted, since we use random number generators).  Enumerated below
are the intended capabilities of the application:

o It should have vehicles enter from the top right which proceed to the left
  and from the bottom left which proceed to the right.
o It should not allow the vehicles to have individual velocities, i.e. all
  vehicles have the same speed.
o It should allow the user to control the density of the traffic via the
  keyboard.

Now that we have a good idea of the capabilities of the application, we can
begin the design with the goals that we have set in mind.

Sprites and Animation (Part 3) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 3.3. Design ΓòÉΓòÉΓòÉ

Design

Because we have an easy to use "create sprite" function, it is easier for us to
create two bitmaps for each vehicle type, one for each direction, and to create
two sprites from these bitmaps.  Although this is not a good design policy, by
knowing which bitmap id's correspond to which vehicle type and direction, we
can build a table of sprite information which contains the following
information:

o the sprite handle
o the direction that the sprite should travel
o the vehicle type
o ...plus other information such as sprite size

The corresponding data structure for this is

#define SIT_CAR                  0x0001L
#define SIT_TRUCK                0x0002L
#define SIT_GOESLEFT             0x0004L
#define SIT_GOESRIGHT            0x0008L

#define SIS_UNUSED               0L
#define SIS_VISIBLE              1L
#define SIS_ENTERTOP             2L
#define SIS_EXITTOP              3L
#define SIS_ENTERBOTTOM          4L
#define SIS_EXITBOTTOM           5L

typedef struct _SPRITEINFO {
   HSPRITE hsSprite;
   SIZEL szlSize;
   ULONG ulType;
   ULONG ulState;
} SPRITEINFO, *PSPRITEINFO;

The explanation of the SPRITEINFO structure follows:

hsSprite            handle of the sprite.
szlSprite           size of the sprite.  This is used to determine the value of
                    ulState.
ulType              type of the sprite and direction it travels (SIT_*
                    constant).
ulState             state of the sprite (SIS_* constant).

   SIS_UNUSED          not currently being used
   SIS_VISIBLE         on screen
   SIS_ENTERTOP        entering on the top half of the road
   SIS_EXITTOP         exiting on the top half of the road
   SIS_ENTERBOTTOM     entering on the bottom half of the road
   SIS_EXITBOTTOM      exiting on the bottom half of the road

Sprites and Animation (Part 3) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 3.4. Animation ΓòÉΓòÉΓòÉ

Animation

The animation itself is nothing more than good management of an array of
SPRITEINFO structures from within a WM_TIMER message. The pseudocode for the
logic is

 1. If nothing is entering on top and a random number is 0, find an unused
    sprite that goes from right to left and set its state to "enter on top".

 2. If nothing is entering on bottom and a random number is 0, find an unused
    sprite that goes from left to right and set its state to "enter on bottom".

 3. For all sprites that are not marked as "unused", increment or decrement
    their horizontal position as appropriate, and update their status to
    reflect if they are entering, on screen, exiting, or no longer visible
    ("unused").

Once you understand this, you should have no trouble interpreting the
corresponding code below:

case WM_TIMER:
   switch (SHORT1FROMMP(mpParm1)) {
   case TID_TRAFFIC:
      {
         HPS hpsWnd;
         PSPRITEINFO psiSprite;
         POINTL ptlPos;
         ULONG ulIndex;

         hpsWnd=WinGetPS(hwndWnd);

         psiSprite=findSprite(pidData->asiSprites,SIS_ENTERTOP,0);
         if ((psiSprite==NULL) && (rand()%pidData->lMod==0)) {
            psiSprite=findSprite(pidData->asiSprites,
                                 SIS_UNUSED,
                                 SIT_GOESLEFT);
            if (psiSprite!=NULL) {
               psiSprite->ulState=SIS_ENTERTOP;

               ptlPos.x=pidData->szlPlay.cx;
               ptlPos.y=pidData->szlPlay.cy/2+40;

               SprSetSpritePosition(hpsWnd,psiSprite->hsSprite,&ptlPos);
               SprSetSpriteVisibility(hpsWnd,psiSprite->hsSprite,TRUE);
            } /* endif */
         } /* endif */

         psiSprite=findSprite(pidData->asiSprites,SIS_ENTERBOTTOM,0);
         if ((psiSprite==NULL) && (rand()%pidData->lMod==0)) {
            psiSprite=findSprite(pidData->asiSprites,
                                 SIS_UNUSED,
                                 SIT_GOESRIGHT);
            if (psiSprite!=NULL) {
               psiSprite->ulState=SIS_ENTERBOTTOM;

               ptlPos.x=(-psiSprite->szlSize.cx);
               ptlPos.y=pidData->szlPlay.cy/2-60;

               SprSetSpritePosition(hpsWnd,psiSprite->hsSprite,&ptlPos);
               SprSetSpriteVisibility(hpsWnd,psiSprite->hsSprite,TRUE);
            } /* endif */
         } /* endif */

         for (ulIndex=0; ulIndex<MAX_VEHICLES; ulIndex++) {
            psiSprite=&pidData->asiSprites[ulIndex];

            if (psiSprite->ulState==SIS_UNUSED) {
               continue;
            } /* endif */

            SprQuerySpritePosition(psiSprite->hsSprite,&ptlPos);

            if ((psiSprite->ulType & SIT_GOESLEFT)!=0) {
               ptlPos.x-=DELTA_X;

               if (ptlPos.x+psiSprite->szlSize.cx<0) {
                  psiSprite->ulState=SIS_UNUSED;
               } else
               if (ptlPos.x<0) {
                  psiSprite->ulState=SIS_EXITTOP;
               } else
               if (ptlPos.x+psiSprite->szlSize.cx>pidData->szlPlay.cx) {
                  psiSprite->ulState=SIS_ENTERTOP;
               } else {
                  psiSprite->ulState=SIS_VISIBLE;
               } /* endif */
            } else {
               ptlPos.x+=DELTA_X;

               if (ptlPos.x>pidData->szlPlay.cx) {
                  psiSprite->ulState=SIS_UNUSED;
               } else
               if (ptlPos.x+psiSprite->szlSize.cx>pidData->szlPlay.cx) {
                  psiSprite->ulState=SIS_EXITBOTTOM;
               } else
               if (ptlPos.x<0) {
                  psiSprite->ulState=SIS_ENTERBOTTOM;
               } else {
                  psiSprite->ulState=SIS_VISIBLE;
               } /* endif */
            } /* endif */

            if (psiSprite->ulState!=SIS_UNUSED) {
               SprSetSpritePosition(hpsWnd,psiSprite->hsSprite,&ptlPos);
            } else {
               SprSetSpriteVisibility(hpsWnd,psiSprite->hsSprite,FALSE);
            } /* endif */
         } /* endfor */

         WinReleasePS(hpsWnd);
      }
      break;
   default:
      return WinDefWindowProc(hwndWnd,ulMsg,mpParm1,mpParm2);
   } /* endswitch */
   break;

You should notice the reference to pidData->lMod in the determination of
whether a sprite is to begin entering the display area.  This is a changing
value which can be adjusted using the "+" and "-" keys; the code is trivial
WM_COMMAND processing with the two keys mapped to accelerators.

ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ

The rest of the code is, honestly, initialization and termination processing
(other than the "standard" PM code).  Everything you need to compile I495.EXE
is provided as I495.ZIP.

Sprites and Animation (Part 3) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 3.5. Summary ΓòÉΓòÉΓòÉ

Summary

This month we said our farewells to this series by examining the animation in a
simple application - I495.EXE.  And while it was said earlier that hard-coded
animations are rare, I would like to conclude that, although rare, a good
animation sequence can spruce up any "About box" (or any other part of an
application) and is well worth the effort of coding it.

Any questions can be sent directly to me via email at the address listed at the
end of this issue.

Sprites and Animation (Part 3) - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 4. /dev/EDM/BookReview ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 4.1. Introduction ΓòÉΓòÉΓòÉ

/dev/EDM2/BookReview

Written by Carsten Whimster

Introduction

/dev/EDM2/BookReview is a monthly column which focuses on development oriented
books and materials.  The column is from a beginning PM programmer's eyes,
because that's what I am.  Pick up whichever book strikes your fancy, and join
the growing group of people following our PM programming columns.  I will
review books aimed at beginners for a while, and then move on from there.

 Please send me your comments and thoughts so that I can make this column as
effective as possible.  After all, the magazine will be more effective with
good reader feedback.

The Art of OS/2 2.1 C Programming finally got here.  It turned out there was
some kind of mix-up but once they realized, it got here double-fast.  It is the
first of a care-package of three books I was sent by Wiley-QED.  I have been
anxiously awaiting this one, and I heard of it long before becoming involved
with EDM/2.  It has a good reputation as a beginner's OS/2 and PM programming
book, and also has a reputation of being hard to find. Hopefully this will
change with time (the availability, that is).

/dev/EDM/BookReview - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 4.2. Errata ΓòÉΓòÉΓòÉ

Errata

I have been very busy this month, what with brain-storming about the layout
design of EDM/2.  Thanks go to Craig Rodrigues (did I get the spelling right? I
don't have my mail here) for suggesting flattening the index a bit.  I have
also been busy reviewing Larry's The Art of OS/2 2.1 C Programming, trying to
set up a universal table of contents for the books I review, which will
hopefully debut next month (thanks Gordon), getting a start on a VX-REXX
article, and setting up a database of ex- and current authors for EDM/2 in an
effort to ensure that the stream of articles coming is more regular.  In
addition, I've been setting and marking assignments and midterms at UW.  Whew.

I have been working a bit on my OS/2 WWW page.  Check it out, and mail me your
thoughts, corrections, and ideas.

On the other hand, is has been quiet with respect to mail from readers.

Watcom C/C++ 10.0 is on its way!  I ordered it Friday June 24, and can hardly
wait.  Supposedly it is just beautiful, and has a very good IDE.  In fact, the
quality is supposedly so high that some people have been heard to complain
about the low quality of the IBM OS/2 2.1 Toolkit, and hope that Watcom makes
their own for the next release of the compiler!  I never really felt a need to
criticize the Toolkit, so 10.0 must be something!  It comes on either 61
diskettes or 1 CD-ROM.  Guess which I ordered :)  A full installation takes up
172Mb (!), but I will only be installing the OS/2 stuff, as I have deep-sixed
both DOS and Windows a long time ago.

I have a small confession to make here.  Ever since Larry asked if I was going
to review his book (well, their book.  Kathleen Panov wrote the largest chunk,
followed by Larry, and lastly Arthur Panov), I have been afraid of two things.
First, what if I didn't like it?  Although we have never met, I feel like I
know him well at this point, and so I wouldn't want to offend him. Secondly, if
I like it, how do I convince people that I am not just giving it a great review
because of our (Internet) connection?  I was a little relieved when Larry sent
me a letter telling me that if I didn't review it fairly, and criticize it
accordingly, then I was fired :)  But I was still nervous.

At some point during my review I decided to be a little more critical than
normal with this book, since I am in the unique position of knowing that it is
in the process of an update, and of knowing that one of the authors is
listening.  Please don't take this extra criticism to heart, but remember why I
am doing this.  Anyhow, on to the review...

/dev/EDM/BookReview - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 4.3. The Art of OS/2 2.1 C Programming ΓòÉΓòÉΓòÉ

The Art of OS/2 2.1 C Programming

The Art of OS/2 2.1 C Programming is an OS/2 programming book for beginners.
It has a few chapters on fundamental OS/2 programming issues such as threads
and IPC, but it is mainly intended as a PM programming book. It comes with a
3.5" diskette, but no installation program.  You are expected to use OS/2's
unpack to copy the files over.  Here are the chapters:

 1. Tools
 2. Memory Management
 3. File I/O and Extended Attributes
 4. Multitasking
 5. Interprocess Communication
 6. Windows and Messages
 7. Dialog Boxes
 8. Menus
 9. List Boxes
10. Buttons
11. Notebook
12. Containers
13. Value Set
14. Spin Buttons
15. Slider
16. Font and File Dialogs
17. Subclassing Windows
18. Drag and Drop
19. Help Manager
20. Presentation Manager Printing
21. Appendix A - References

Chapter one is on C-Set++ and the OS/2 Programmer's Toolkit 2.1, and is a very
brief introduction to the usage of the various tools included.  I'll have more
to say about that in the summary.

Chapters two through five discuss some fundamental OS/2 programming techniques,
many of which are crucial to certain types of programs.  For example, anything
network related or network aware will probably need pipes, named pipes, IPC, or
other goodies.  All programs should use good memory management and most should
probably use use threads.  Most programs use files. This early coverage of
these topics allows you to see clearly how to use the appropriate calls,
without having to sift through the guts of a PM program's code to try to
extract the necessary information.  These first few chapters are interesting,
instructive and well-written.

The real PM programming issues start in chapter six.  This chapter is an
introduction to the basic APIs and structure used in a PM program.  First, you
must get a handle to an anchor block.  Next, you set up a message queue, and
register your program's class with OS/2.  Then you create your window with
whatever options you want.  Finally, the message loop is set up, and when the
program exits this, it cleans up and quits.  The window procedure is explained
last, which wraps up your basic PM application.  To this basic skeleton many
frills can be added, and chapter six introduces a few of them.

There are an incredible number of messages and defined constants in OS/2 PM
programming, and this book does a good job of listing and explaining the
important ones.  Occasionally, I felt that a bit more of an explanation was in
order; an explanation by way of a sample use is the easiest to understand.
Chapter six lists a lot of these, and it is a fairly big and hairy chapter to
get through.  Since anyone reading this chapter will be a first-time PM
programmer, I feel that pulling the constants and messages into a new chapter
seven, with lots of forward references to them, would be helpful to the
organization of the book.  Either that, or split the chapter into an
introductory and an intermediate fundamental window programming chapter.  The
reason I mention this is that I practically flew through the first five
chapters, but took the longest time to get through chapter six.  The sheer
amount of material and data in this chapter hinders learning a bit, I find.  I
also find the WM message section at the end of the chapter a little lacking in
readability.  Anyhow, onwards we go...

By the wayside, I love the little "Gotcha!"  sections that explain and warn
about certain things.  I find that they really enhance the understanding of the
material, and add a little extra interest too.

The next two chapters on dialog boxes and menus are both short and sweet. They
present the necessary information, and not much more.  Both ways of creating
and designing dialog boxes are explained, and all basic types of menus are
demonstrated.  Again, however, I found the message sections at the end of the
chapters a little hard to read, and it is hard to find what you want there, or
even to know what you are looking for.  A slightly different layout, and a few
more explanations of intended usage would probably go a long way towards
alleviating this.

The next two chapters on list boxes and buttons are a little sparse.  Only the
resource file creation method is demonstrated, which doesn't satisfy all uses.
The examples are a little too simplistic; perhaps another one or two should be
added to each chapter.  For example, the listbox sample doesn't demonstrate how
to add items, delete items, and so on, and the button example doesn't
demonstrate how to do anything useful with the buttons; it only shows you what
the various styles look like.  On my screen (1024x768x256 svga with a modified
ibmdev32.dll) the information icon overflows the borders of the icon button a
bit.  I suppose that may be my fault for modifying ibmdev32.dll for the smaller
32x32 icons, but I wonder if there is some logical way of fixing it, or
programming around it?

The notebook and container chapters are both good, and pretty thorough. The
only thing I missed was a run-down on the BKA constants for notebook.  The
other constants are listed, why not these?  They are mentioned in the text,
however.

Another little note here:  throughout the text there are little hints on style,
mainly following the CUA guidelines.  This is a great idea, since a lot of
books skip this.  It is not always intuitive which way of doing something will
yield the best results, and the people who designed the CUA guidelines have
spent a lot of time studying interfaces and so on.  In general, your
applications should follow the CUA guidelines quite closely, unless you have a
very specific reason for deviating from them.  This will insure that most
application can be learned quickly and easily.  On the other hand, who has the
time to find, get, and read the CUA documents?  The hints in this book help you
make the right decisions.

In the spin-button chapter, code is finally given to create a control right in
the application instead of jumping to some dialog.  Unfortunately, I didn't
have the luxury of knowing my window size ahead of time like the example code
did, so I had to resort to other methods of calculating the spin-button
position for me program.  I tried to post a user-defined message to myself from
the WM_CREATE message handling as suggested in chapter six, but could not get
this to work.  No matter what I did, the WinQuerySysValue returned a size of
zero for the window.  It would have been good to see some real code to do this.
The rest of the functionality of the spin-button is well-explained, though.
The use of accelerator keys to jump from spin-button to spin-button is neat.

A third note:  many of the programs supplied run badly when run from another
directory.  The slides programs are one example.  When run from the parent
directory, the ribbon-strip doesn't show up.  Giving an error would have been
preferable, I think.  I am not really sure why they act like this. Because of
the numerous directories for the sample programs, I was running the programs
from the parent directory until I realized that some of them didn't work when
run like this.  (Just in case this is a bug in the OS, I am running the 2.11
CSD for OS/2 2.1 GA.)

The slider chapter has some neat thread and object-window examples, but I
missed an example on a non-read-only slider.  Considering that there are three
(!) sample programs for this chapter, I think there should be at least one on a
regular slider.  Apart from that, it is good.

The standard file and font dialog chapter has a standard example of each type.
Perhaps it would have been nice with another tweaked example, but this will get
most people started.

Subclassing windows is a very important topic for anyone interested in doing
things a little differently than the designers of OS/2 had envisioned. Most of
the controls have a very tightly defined standard behaviour which doesn't
always suit your needs.  Subclassing windows gives you the opportunity to keep
what behaviour you like, and modify what you don't.  As an example, look at
EPM.  It has extra buttons on the title for rotating through the files you have
loaded.  This was most likely accomplished through subclassing the titlebar
window.  Unfortunately, IBM designed EPM with slightly different button shading
depth for these buttons, so it looks a little odd, but it works in any case.
Subclassing requires that you write an alternate window procedure for the
window in interest to handle the different behaviour, and then pass the rest of
the messages on to the original window procedure.  This chapter explains this
concept well with a nice flow-chart.  I would have liked to see another, more
complicated example, but the one supplied does demonstrate the basics.

The drag and drop chapter introduces what is probably a fairly alien concept to
most programmers.  We have likely all used it, but few of us realize what
really goes into programming this behaviour.  It is a little weird-alice, but
there are two examples to help us along.  Unfortunately, both examples have the
minimized icon behaviour disabled, so it is impossible to tell how much of what
was programmed will work on an icon, and how much won't. It would have been
informative to have at least one of these examples demonstrate this.  The
chapter otherwise does an excellent job of explaining what is a difficult
topic.

The subject of help is one of my favorites.  Obviously, writing for this
magazine gives me a unique depth of knowledge of IPFC and the INF format
compared to normal programmers.  In addition to this, I have always been extra
pleased when I have used a program for which the author took the time to write
a really good help interface.  There is nothing more frustrating than looking
up the help for the control that is supposed to accomplish function X, but
which you are having trouble getting to work, and reading either "This control
does X", or "This is the help file.  This program does XYZ."  but no specific
help on what you are looking for.  The help is one of the most important
details, because it tells your user what to do when your best efforts at making
your application intuitive have failed.  The help chapter is one of the best in
the book.  It is well organized, and the example covers pretty well everything
that you need to know.  It is NOT a tutorial on how to make IPF documents, but
then the Toolkit covers that pretty well.  The example goes one step further
than is common in showing how to set up a chain of help through a message box,
and into the help document, if required.  It is good to see that this important
topic has recieved the full treatment it needs.  A lot of shareware programs
out there, and even some commercial programs (even some IBM programs, but I
won't mention that) have abysmal help facilities.  When evaluating a program,
if I run into a snag and the help facility is poor, then the program usually
goes the way of the dodo bird immediately.  I don't often feel like using Zen
to try to imagine what the "right way" of doing something is.  If the help
isn't helpful, it can seriously ruin the enjoyment of an otherwise good
program.  Lecture over.  By the way, this chapter's example program is another
that doesn't run from the parent directory.  This is understandable, since it
can't find the help file, but it should really give an error message instead of
just not working.  Luckily by this time I was accustomed to jumping into the
proper directory.

The final chapter of the book is on Presentation Manager printing.  This is a
topic which I have traditionally skipped over lightly, partly because I don't
have a printer.  I use the printers at school whenever I need to print a
resume, or whatever.  A second reason is that I don't tend to write programs
which need to print, like most of us.  BUT, since it is the last chapter of an
otherwise enjoyable book, I decided to read it anyway.  As I have come to
expect by this time, the chapter is well written, covers the basics well, and
makes sure that when you do have questions which this book can't answer, you
are ready for a more advanced book anyway.  The example doesn't do much fancy
printing, but then that should probably be covered in a different type of
chapter anyway.  It does give a proper foundation in setting it all up, and
shows you the potential pitfalls to avoid.

Well, that's the book.  Appendix A has references to all the standard reference
books you could want.

/dev/EDM/BookReview - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 4.4. Summary ΓòÉΓòÉΓòÉ

Summary

Ever since I opened The Art of OS/2 2.1 C Programming  and started reading
through the chapters, I realized that this would become one of my favorite OS/2
programming books.  It is an easy read, but reasonably thorough in its coverage
of the basic issues.  It has humour, which you'll realize is important to me,
if you have been following my column at all.  It doesn't assume too much
knowledge from you, but it doesn't treat you like a dolt either.  I can
recommend this book with a clear conscience to anyone starting out in GUI and
OS/2 PM programming.  It needs a few additions, but is reasonably complete in
its current state.  Including a few introductory OS/2 chapters on basic
(non-PM) matters was a stroke of brilliance.  It isn't obvious at all how
important it is to include this until you read the book, and think "why isn't
this in my other books?".  Anyhow, enough evangelizing.

I debated with myself for a long time about whether to give this book an A- or
a B+.  I finally decided that there were too many little niggling things which
I would like to see fixed to give it an A-, so B+ is what it got.  This book
obviously has very good potential though, and could easily be improved with a
revision.

There are a few of suggestions I would like to make:

o  This book really should support compilers other than just C-Set++.  I
  personally own Watcom C/C++ 9.5 (and soon 10.0), and had to use the makefile
  from Real World Programming for OS/2 2.1 to get the programs to compile.  I
  imagine Borland C++ owners (of which I am one, although I don't use it) and
  owners of other compilers have similar problems.  Similarly, the tools
  chapter only describes the OS/2 2.1 Toolkit.  Watcom C/C++ uses the Toolkit,
  but Borland C++ has its own tools, so Borland C++ programmers are left out in
  the cold a bit.  And what about EMX?  Ideally, the book should support IBM
  C-Set++ (both FirstStep and the full-blown version; they should be the same),
  Watcom C/C++ 9.5 and 10.0, Borland C++ 1.0 and 1.5, EMX, and Symantec's C++
  compiler, maybe even MetaWare's High C++ (is that the right name?)  and
  MicroWay's C++ compiler.  At the very least, C-Set++, Watcom C/C++, Borland
  C++, and GNU makefiles should be covered.  We can't all afford C-Set++ :)
o The diagrams in the book are a little cheap-looking, considering that we are
  dealing with a tour-de-force in graphical environments, OS/2 2.1.  That is
  probably the luck of the draw when you are a new author, though.  Hopefully
  this will be alleviated in the next edition.
o The sample programs really need a graphical installation program.  I was
  unlucky, and got a pseudo-bad disk, and only after much fiddling was I able
  to install and unpack all the samples.  The disk wouldn't be the authors'
  fault, but the installation procedure is.
o Chapters on SOM, WPS, GPI, interfacing with REXX, DLLs, bitmaps, colour
  palettes, and perhaps an intro to C++ should be added.  I have been
  considering recommending an introductory VIO chapter, but I am not sure
  whether that is a good idea, since VIO is old hat.  On the other hand, VIO
  programs certainly do fill a niche.  A chapter should be added with loose
  ends like WinMessageBox().
o The index needs beefing up too, roughly doubling should do.  One can't always
  know the thing one is looking for by name, and there are very few keyword
  topics in the index.
o More depth is needed in control window creation and manipulation, like sizing
  them upon window creation when you don't know what size your window will be,
  resizing list boxes on the fly and so on.  A lot of the example code is
  dialog template based, and there aren't a lot of examples on how to create
  and manipulate the various windows right in your application.  When I had to
  do this, I found it helpful to peek in another one of my books.

Note that I am nit-picking here.  These are more after-thoughts than things I
really missed when I went through the first time, except for the window
creation and manipulation stuff.  Consider this "polishing" what in many ways
is a great book.

I have been told that there is a revision on the way, with more in-depth
coverage, and new chapters on key subjects, but that's all I know so far.  If
the stuff is added I mentioned above, this book should easily qualify for an A,
maybe even an A+.  Of course, if everything I mentioned was added, then the
book would probably be more of a beginning and intermediate programmer book,
and it would be much larger too :)

/dev/EDM/BookReview - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 4.5. Books Reviewed ΓòÉΓòÉΓòÉ

Books Reviewed

This table contains all books I have reviewed, so that you can find what you
are looking for at a glance.  I will be careful to rate books fairly.  If I
feel a need to adjust ratings, I will adjust all of them at the same time, and
write a note explaining why I felt this necessary.  Please note that books
aimed at different audiences should only be compared with great care, if at
all.  I intend to concentrate on the strong points of the books I review, but I
will point out any weaknesses in a constructive manner.

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéBOOK                                ΓöéAUDIENCE    ΓöéMARKΓöéCOMMENTS                                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéReal-World Programming for OS/2 2.1,ΓöéIntermediateΓöéB+  ΓöéLots of good code examples, but sometimes it is  Γöé
ΓöéBlain, Delimon, and English, SAMS   Γöéto Advanced Γöé    Γöétoo complex for novices. Accurate.  Well         Γöé
ΓöéPublishing. ISBN 0-672-30300-0.     ΓöéPM C        Γöé    Γöéorganized.  The index needs a little beefing up. Γöé
ΓöéUS$40, CAN$50.                      Γöéprogrammers Γöé    ΓöéGood, but not entirely complete how-to reference.Γöé
Γöé                                    Γöé            Γöé    ΓöéGood purchase.                                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéLearning to Program OS/2 2.0        ΓöéBeginning PMΓöéB-  ΓöéThis book can be both frustrating and very       Γöé
ΓöéPresentation Manager by Example,    ΓöéC           Γöé    Γöérewarding.  It is not very large, and a bit      Γöé
ΓöéKnight, Van Nostrand Reinhold. ISBN ΓöéProgrammers Γöé    Γöépricey, but has some excellent chapters on       Γöé
Γöé0-442-01292-6. US$40, CAN$50.       Γöé            Γöé    Γöécertain beginning topics, such as messages,      Γöé
Γöé                                    Γöé            Γöé    Γöéresources, IPF, and dialog boxes.  Strictly for  Γöé
Γöé                                    Γöé            Γöé    Γöébeginners.  This book has only one (large) sampleΓöé
Γöé                                    Γöé            Γöé    Γöéprogram!                                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéWriting OS/2 2.1 Device Drivers in  ΓöéAdvanced C  ΓöéA-  ΓöéThe only thing a device driver programmer would  Γöé
ΓöéC, 2nd Edition, Mastrianni, Van     ΓöéProgrammers,Γöé    Γöénot find in here is how to write SCSI, ADD, and  Γöé
ΓöéNostrand Reinhold. ISBN             Γöéfamiliar    Γöé    ΓöéIFS drivers.  Most everything else is in here,   Γöé
Γöé0-442-01729-4. US$35, CAN$45.       Γöéwith        Γöé    Γöéalong with skeleton examples.  An optional DevHlpΓöé
Γöé                                    Γöéhardware    Γöé    Γöélibrary of C-callable functions can be purchased Γöé
Γöé                                    Γöéprogramming Γöé    Γöéby those who don't have time to write their own. Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéOS/2 Presentation Manager GPI, Winn,ΓöéIntermediateΓöéC+  ΓöéThis book needs updating for OS/2 2.x.  It is a  Γöé
ΓöéVan Nostrand Reinhold. ISBN         Γöéto advanced Γöé    Γöéwell-written in-depth coverage of the OS/2 way ofΓöé
Γöé0-442-00739-6. US$35, CAN$45.       ΓöéPM C        Γöé    Γöéprogramming for graphics.  It is not an          Γöé
Γöé                                    Γöéprogrammers Γöé    Γöéintroductory PM or graphics programming book.    Γöé
Γöé                                    Γöé            Γöé    ΓöéYou should know the basics of PM programming     Γöé
Γöé                                    Γöé            Γöé    Γöéalready.                                         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéThe Art of OS/2 2.1 C Programming,  ΓöéBeginning   ΓöéB+  ΓöéThis is a great introductory PM programming book.Γöé
ΓöéPanov, Salomon, and Panov,          ΓöéOS/2 and PM Γöé    ΓöéIt covers basic OS/2 issues like threads before  Γöé
ΓöéWiley-QED. ISBN 0-471-58802-4.      Γöéprogrammers Γöé    Γöéit jumps into PM programming.  The coverage is   Γöé
ΓöéUS$40, CAN$50.                      Γöé            Γöé    Γöéquite thourough, with just enough reference      Γöé
Γöé                                    Γöé            Γöé    Γöématerial to make it useful after you read it     Γöé
Γöé                                    Γöé            Γöé    Γöéthrough the first time.  The upcoming revised    Γöé
Γöé                                    Γöé            Γöé    Γöéedition should be a killer.                      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

LEGEND:

BOOK:  The name of the book, author(s), publishing company, ISBN, and
approximate price.

AUDIENCE:  This is a description of the audience I think the book targets best.
This is not intended as gospel, just a guideline for people not familiar with
the book.

MARK:  My opinion of the success of the book's presentation, and how well it
targets its audience.  Technical content, accuracy, organization, readability,
and quality of index all weigh heavily here, but the single most important item
is how well the book covers what it says it covers.

ΓöîΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéA+ ΓöéGround-breaking, all-around outstanding book                                 Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéA  ΓöéExcellent book. This is what I want to see happen a lot                      Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéA- ΓöéExcellent book with minor flaws                                              Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéB+ ΓöéVery good book with minor flaws or omissions                                 Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéB  ΓöéGood book with some flaws and omissions                                      Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéB- ΓöéGood book, but in need of improvement                                        Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéC+ ΓöéMediocre book with some potential, but in need of some updating              Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéC  ΓöéMediocre book with some good sections, but badly in need of fixing           Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéC- ΓöéMediocre book, little good material, desperately in need of an overhaul      Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéD  ΓöéDon't buy this book unless you need it, and nothing else exists              Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéF  ΓöéDon't buy this book. Period                                                  Γöé
ΓööΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

COMMENTS:  This is a very brief summary of the review proper.

/dev/EDM/BookReview - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 4.6. Coming Up ΓòÉΓòÉΓòÉ

Coming Up

Next month I will be looking at Mastering OS/2 REXX, Gargiulo. The books I
intend to review are (not necessarily in this order):

o Mastering OS/2 REXX, Gargiulo
o Application Development Using OS/2 REXX, Rudd
o OS/2 Presentation Manager Programming, Petzold - 1994 - not yet published.
o The Design of OS/2, 2nd Edititon, Kogan and Deitel - 1994 - not published yet

I am considering reviewing the IBM OS/2 Redbooks, since they are readily and
cheaply available, and look like good reference.

I am also considering reviewing Designing OS/2 Applications, Reich, mostly
because it promises to present a different angle on OS/2 programming, namely
that of how to design OS/2 applications, rather than how to program OS/2
applications.

Finally, I am considering reviewing OS/2 Unleashed, but it is not strictly
speaking a development book, so I'm going to wait until the list of real
development books has diminished a bit.  By the way, does anyone know why the
special edition of OS/2 Unleashed  has different authors? And what is different
about the Special Edition?

If anyone has a book they want to see reviewed, I will be happy to oblige as
long as I can afford it.  Of course, requests can be satisfied quicker when
accompanied by a book :)  Publishers can send me books at the address on my
personal page at the end of the magazine, and I will review all OS/2
development-related and advanced user books I receive.

/dev/EDM/BookReview - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 5. C++ Corner ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 5.1. Introduction ΓòÉΓòÉΓòÉ

C++ Corner

Written by Gordon Zeglinski

Introduction

Profile Files (aka INI files) are used in most OS/2 applications.  In this
issue, we will look at the profile API and then encapsulate it with in a group
of C++ classes.

C++ Corner - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 5.2. The Profile API ΓòÉΓòÉΓòÉ

The Profile API

In this section, we will look at the functions in the profile API that will be
used to create the C++ classes.

Opening the File

Before we can read or write to our own profile files, we must open the profile
file.  The PrfOpenProfile() function returns a handle to the opened profile
file, and takes an anchor block handle and file name as arguments.  The
function prototype follows:

HINI PrfOpenProfile(HAB hab,PSZ ProfileName)

Closing the File

Of course, we should close any INI file we open.  The handle returned by
PrfOpenProfile() is this function's only argument.

BOOL PrfCloseProfile(HINI hini)

Profile File Structure

Now that we can open and close profile files, we need to write and read from
them.  Before we can proceed, however, we will look at how profile files are
organized.  Data is stored by an application name and key name.  Both the
application and key names are strings.  One can conceptually think of the file
structure as follows:

ΓòöΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòù
ΓòæApplication 1Γòæ
ΓòÜΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓò¥
   ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
   ΓöéKey 1Γöé
   ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
      Data 1
   ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
   Γöékey 2Γöé
   ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
      Data 2

ΓòöΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòù
ΓòæApplication 2Γòæ
ΓòÜΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓòÉΓò¥
   ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
   ΓöéKey 1Γöé
   ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
      Data 1

Keys within a given application must be unique, but they do not have to be
unique within the profile file.  Application strings must be unique within the
profile file.

Writing Data

Data can be written to the profile file using either of the following
functions:

BOOL PrfWriteProfileData(HINI hini,
                         PSZ pszApp,
                         PSZ pszKey,
                         PVOID pData,
                         ULONG cchDataLen);
BOOL PrfWriteProfileString(HINI hini,
                           PSZ pszApp,
                           PSZ pszKey,
                           PSZ pszData);

The pData parameter in PrfWriteProfileData() is the address of the data to be
written while cchDataLen is the length of the data.  This function can be used
to write binary data to the profile file, while the PrfWriteProfileString()
function writes a NULL terminated string only.

Reading Data

The profile file API provides three functions which can be used to read in data
from the application/key pair.  Two of these functions are just the inverse of
the two read functions, while the third function converts a number stored as a
string into an integer.  Finally, there is a function which returns the length
of the data stored under an application/key pair.  The prototypes for these
functions follow:

BOOL PrfQueryProfileData(HINI hini,
                         PSZ pszApp,
                         PSZ pszKey,
                         PVOID pBuffer,
                         PULONG pulBufferMax);
ULONG PrfQueryProfileString(HINI hini,
                            PSZ pszApp,
                            PSZ pszKey,
                            PSZ pszDefault,
                            PVOID pBuffer,
                            ULONG cchBufferMax);
LONG PrfQueryProfileInt(HINI hini,
                        PSZ pszApp,
                        PSZ pszKey,
                        LONG lDefault);
BOOL PrfQueryProfileSize(HINI hini,
                         PSZ pszApp,
                         PSZ pszKey,
                         PULONG pDataLen);

The functions PrfQueryProfileSize() and PrfQueryProfileData() can be used to
enumerate the application and key values (see the PM Reference for details).
The functions PrfQueryProfileString() and PrfQueryProfileInt() allow the
programmer to specify default values.  This is very handy when the application
is executed for the first time and its profile information may not be present.

C++ Corner - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 5.3. Encapsulating The Profile API ΓòÉΓòÉΓòÉ

Encapsulating The Profile API

As with all first attempts at encapsulation, we will wrap the profile API
loosely with a C++ class.  To do this, we will have have member functions for
reading and writing data, and data members to store the profile file's name and
handle.  Following is the class definition for the base ProfileFile class:

class ProfileFile {
   APIRET Error;
   HINI hini;
   HAB hab;
   PSZ FileName;
   char Close;

public:
   ProfileFile(PSZ name,HAB hb);
   ProfileFile(HINI H);
   ~ProfileFile();

   APIRET GetError() { return Error; }
   HINI GetHandle() { return hini; }

   void WriteString(PSZ App,PSZ Key,PSZ String);
   void WriteData(PSZ App,PSZ Key,void * Buff,ULONG BLen);
   ULONG GetDataSize(PSZ App,PSZ Key);
   void GetData(PSZ App,PSZ Key,void * Buff,ULONG & BufMax);
   ULONG GetString(PSZ App,PSZ Key,PSZ Buff,ULONG BufMax,PSZ DefArg=NULL);
   LONG GetInt(PSZ App,PSZ Key,LONG DefArg=0);
   void WriteInt(PSZ App,PSZ Key,LONG Num);
   PRFPROFILE Querry();
};

You will notice that each of the API functions we looked at has a corresponding
member function.  In addition, we added a function to write an integer that can
be read later by the GetInt member function.

The system and user INI files, have predefined handles.  We will subclass
ProfileFile to allow us to use the same encapsulation method on the system and
user INI files.  Following are the definitions of these two classes:

class UserProfile:public ProfileFile {
public:
   UserProfile():ProfileFile(HINI_USERPROFILE) { }
};

class SystemProfile:public ProfileFile{
public:
   SystemProfile():ProfileFile(HINI_SYSTEMPROFILE) { }
};

The use of these classes is pretty straight forward.  The following sample code
will show some of the basics.

void main() {
   ProfileFile AppINI("APP.INI");   // open an application ini file (app.ini)
   UserProfile UserINI;             // open the user ini file (os2.ini)

   char SomeString[30];

   AppINI.GetString("Application","Key",SomeString,29,"Default String");

   UserINI.WriteString("Application","Key",SomeString);

}

The above program opens the file "APP.INI", then attempts to read a string from
this file.  If the application/key pair is not present, SomeString will contain
the value "Default String" on return from GetString.  SomeString is then
written to the user INI file under the application/key pair
"Application"/"Key".

The files INIFLOBJ.H and INIFLOBJ.CPP contain the source code necessary to
compile the profile classes.

C++ Corner - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 5.4. Summary ΓòÉΓòÉΓòÉ

Summary

In this issue, we have examined the profile file API and encapsulated it. You
should now be able to use profile files in your application.

C++ Corner - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 6. Introduction to PM Programming ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 6.1. Introduction ΓòÉΓòÉΓòÉ

Introduction to PM Programming

Written by Larry Salomon, Jr.

Introduction

The purpose of this column is to provide the readers out there who are not
familiar with PM application development the information necessary to satisfy
their curiousity, educate themselves, and give them an advantage over the
documentation supplied by IBM.  Of course, much of this stuff could probably be
found in one of the many books out there, but the problem with books in general
is that they don't answer the questions you have after you read the book the
first time through.

I will gladly entertain feedback from the readers about what was "glossed over"
or what was detailed well, what tangential topics need to be covered and what
superfluous crap should have been removed.  This feedback is essential in
guaranteeing that you get what you pay for.  :)

It should be said that you must not depend solely on this column to teach you
how to develop PM applications; instead, this should be viewed as a supplement
to your other information storehouses (books, the network conferences, etc.).
Because this column must take a general approach, there will be some topics
that you would like to see discussed that really do not belong here.  Specific
questions can be directed to the Scratch Patch, where an attempt to answer them
will be made.

Last Month

Last month, we finished the WC_ENTRYFIELD window class.  This month, we begin
looking at the WC_LISTBOX window class, how it is used, what its limitations
are, and some of the messages associated with it.

Introduction to PM Programming - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 6.2. Listboxes ΓòÉΓòÉΓòÉ

Listboxes

So what is a listbox anyway?  A listbox is, as you probably well know, a
collection of items.  While originally intended for text only, ownerdraw
listboxes allow you to place graphics, multicolored text, or whatever as long
as you can code it.  When the listbox was originally introduced in OS/2 1.1, it
allowed for single and multiple selection only; the former deselected any
currently selected item whenever a new one was selected by the user or the
application, while the latter allowed for one or more items to be selected at
any one time.  When OS/2 2.0 was released, a third selection style - extended
selection - was added which differed from multiple selection in that it was CUA
in design (multiple selection was not).

To aid in the somewhat object-oriented design, listbox items can have
associated with them handles, which are nothing more than a ULONG that is
unique to a particular item.  This ULONG is typically used to point to a data
structure which contains information about the item, e.g.  printer information
associated with a name which is displayed.  When the user selects the printer
name, the application can get the rest of the information needed to open the
printer device by checking the handle and following the pointer there.

Unfortunately, the designers of the listbox were constrained to the heaps that
were provided by PM for their memory allocation and heaps were limited to 64K
in size, so the listbox must contain all of its housekeeping data in 64K.  The
number of items that this maps to varies, based on the total length of the item
text, but you typically cannot get more than 32K of items (and that much only
if you are lucky) in a single listbox.  To get around this limitation, you must
use the container control or read the article series in the OS/2 Developer
beginning with the January/February issue which develops a replacement class
for the listbox.

Introduction to PM Programming - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 6.3. Messages ΓòÉΓòÉΓòÉ

Messages

Let's take a look at the more commonly used messages.

LM_INSERTITEM

This message is sent to insert an item into a listbox.

Parameters

   param1

      usIndex (USHORT)

         the index where the item is to be inserted.  If LIT_END, the item is
         inserted at the end of the list.  If LIT_SORTASCENDING or
         LIT_SORTDESCENDING, the item is inserted in the appropriately sorted
         order.

   param2

      pchText (PCHAR)

         pointer to the string to be inserted.

Returns

   reply

      lIndex (LONG)

         LIT_ERROR an error occurred.
         index     0-based index of inserted item

LM_QUERYSELECTION

This message is sent to query the index of the selected item.

Parameters

   param1

      ulReserved (ULONG)

         Reserved, 0.

   param2

      ulReserved (ULONG)

         Reserved, 0.

Returns

   reply

      lIndex (LONG)

         LIT_NONE  no item is selected
         index     0-based index of inserted item

LM_SETSELECTION

This message is sent to set the selected state of an item.

Parameters

   param1

      lIndex (LONG)

         0-based index of the item whose selection state is to change

   param2

      bSelect (BOOL)

         TRUE      the item is to be selected
         FALSE     the item is to be unselected

Returns

   reply

      bSuccess (BOOL)

         TRUE      successful completion
         FALSE     an error occurred

LM_SETITEMHANDLE

This message is sent to set the handle for an item.

Parameters

   param1

      lIndex (LONG)

         0-based index of the item whose handle is to be set.

   param2

      ulHandle (ULONG)

         handle to be associated with this item.

Returns

   reply

      bSuccess (BOOL)

         TRUE      successful completion
         FALSE     an error occurred

LM_QUERYITEMHANDLE

This message is sent to return the handle associated with an item.

Parameters

   param1

      lIndex (LONG)

         0-based index of the item whose handle is to be set.

   param2

      ulReserved (ULONG)

         Reserved, 0.

Returns

   reply

      ulHandle (ULONG)

         LIT_ERROR an error occurred
         handle    handle of the specified item.

These should be fairly trivial to use, since the concepts behind them are not
the difficult to understand.  Next month, we'll continue with the remaining
messages and will begin to look at the rest of nameDlgProc().

Introduction to PM Programming - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 7. Scratch Patch ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 7.1. Introduction ΓòÉΓòÉΓòÉ

Scratch Patch

Written by Larry Salomon, Jr.

Introduction

Welcome to this month's "Scratch Patch"!  Each month, I collect various items
that fit into this column sent to me via email. The ones that I feel contribute
the most to developers, whether in terms of information or as a nifty trick to
tuck into your cap, get published in this column.

To submit an item, send it via email to my address - [e-mail] - and be
sure to grant permission to publish it (those that forget will not be
considered for publication).

Scratch Patch - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 7.2. Questions and Answers ΓòÉΓòÉΓòÉ

Questions and Answers

Carsten Haerle ([e-mail]) writes:

I have a simple but interesting question concerning the help menu in PM
applications.  I searched for hours and days but I didn't find the answer to
it.  Even all the documentation in the toolkit, the developers connection and
the DAP library volume didn't give me an answer, or they are even inconsistent.
I think an answer would be of high value to all PM app developers so it would
be a good idea to publish in EDM/2 (if someone finds an answer to it).

Now for the question(s).

 1. What is the correct resource definition of the 'Help' menu.  In some
    documentation I read there should be an MIS_HELP flag, some didn't set the
    flag.  The same with MIS_SYSCOMMAND for the help menu items (and using menu
    id such as SC_HELPFORHELP).  I suppose that question 2) is probably solved
    by the Help Manager if one has the correct help menu definition.
 2. What is the definition and code for the help menu to use OS/2 standard help
    texts for e.g.  'Using Help'.  In addition OS/2 has standard help text
    items for the explanation of the help menu items, i.e.  if you go on the
    'Using Help' menu and press F1.  I manually discovered that displaying
    these help panels can be accomplished by sending the Help Manager the
    following help panel numbers, but I wonder where they are documented:

    Help for menu items:

   o 'Help Index' - 64026
   o 'General Help' - 64024
   o 'Using Help' - 64023
   o 'Keys Help' - 64025
   o 'Help' menu itself - 64022

To answer your first question, there is no correct way.  If you use the
MIS_HELP flag, you have to intercept the WM_HELP message just like you would
have to intercept the WM_COMMAND message without the MIS_HELP flag.  For
consistency, I usually omit the flag.  What you do with the items is fairly
standard (this answers your second question):

o For "Help Index", send the Help Manager an HM_HELP_INDEX message.

o For "General Help", send it an HM_EXT_HELP message.

o For "Using Help", send it an HM_DISPLAY_HELP message with the two parameters
  set to 0.

o For "Keys Help", send it an HM_KEYS_HELP message, to which it will respond by
  sending you an HM_QUERY_KEYS_HELP message.  The proper reply is to send the
  resource id of the keys help panel.

Scratch Patch - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 7.3. Snippet(s) of the Month ΓòÉΓòÉΓòÉ

Snippet(s) of the Month

John Bijnens ([e-mail]) writes:

A week ago I asked you if there was an OS/2 equivalent for errno and
sys_errlist[].  You answered me no then.  I've found now that it is possible to
get the message string that belongs to an error number.  The file OSO001.MSG
that can be found in the directory \OS2\SYSTEM contains all the error messages.
By using the function DosGetMessage you can get the text string that goes with
a certain error number.  So if you now have an error returned by DosRead() (for
example) you can get the corresponding text string.

I've included a small source listing below.  You're free to do with it what you
like.  Perhaps it is of use for someone.

[Editor's note - the source is in the file DOSERROR.C]

ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ

Klaus Johannes Rusch ([e-mail]) writes:

One of the deficiencies of the REXX language is the limitation to one return
value.  While external data queues and files are possible means of
communication, the code snippet below offers superior performance and
usability.

This also proves useful when writing structured data of arbitrary length and
contents to a file.  (Admittedly, this was the author's first use of the
Return() and ParseReturned() functions.)

Return:
  Return '|' || C2X(ARG(1));

ParseReturned:
  Return X2C(SUBSTR(ARG(1), 2));

The following example shows how to use these functions to return multiple
values of arbitrary length and content:

/* REXX */
Parse Value MyProc(parms) With r1 r2 r3;
r1 = ParseReturned(r1);
r2 = ParseReturned(r2);
r3 = ParseReturned(r3);
/* : */
Exit 0;

MyProc: Procedure;
 Parse Arg parms;
 /* : */
 Return Return(r1) Return(r2) Return(r3);

[Editor's note - the source is in the file RETSAMP.CMD]

Scratch Patch - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 7.4. Want Ads ΓòÉΓòÉΓòÉ

Want Ads

Below are the hot topics as of this issue's writing.  Feel free to write on any
of these.

Workplace Shell Programming (hot) - this is still quite the "black magic"
topic, about which we have seen only one article.  There are many out there who
do WPS programming for a living, but they have not been sufficiently
enlightened about our need. :)

Client/Server (hot) - using either named pipes (with or without a network) or
sockets, client/server programming is all the rage these days.  On a related
note, some people have also expressed an interest in learning about interfacing
with the various protocol drivers (e.g.  NDIS, IPX/SPX, etc.).  Any articles in
this area are most welcome.

Multimedia (warm) - we recently had two articles on this topic.  However, they
both dealt with sound, which we all know is not the only alternative media
type.  Articles on anything else - MIDI, video, etc. - are needed.

Scratch Patch - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 8. Contributors to this Issue ΓòÉΓòÉΓòÉ

Are You a Potential Author?

We are always looking for (new) authors.  If you have a topic about which you
would like to write, send a brief description of the topic electronically to
any of the editors, whose addresses are listed below, by the 15th of the month
before the month in which your article will appear.  This alerts us that you
will be sending an article so that we can plan the issue layout accordingly.
After you have done this, get the latest copy of the Article Submission
Guidelines  from ftp.cdrom.com  in the /pub/os2/2_x/program/newsltr directory.
(the file is artsub.zip)  The completed text of your article should be sent to
us no later than five days prior to the last day of the month; any articles
received after that time may be pushed to the next issue.

The editors can be reached at the following email addresses:

o Larry Salomon - [e-mail] (Internet).
o Carsten Whimster - [e-mail] (Internet).

The following people contributed to this issue in one form or another (in
alphabetical order):

o Larry Salomon, Jr.
o Carsten Whimster
o Gordon Zeglinski
o Network distributors

Contributors - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 8.1. Larry Salomon, Jr. ΓòÉΓòÉΓòÉ

Larry Salomon, Jr.

Larry Salomon, Jr. wrote his first Presentation Manager application for OS/2
version 1.1 in 1989.  Since that time, he has written numerous VIO and PM
applications, including the Scramble applet included with OS/2 and the
I-Brow/Magnify/Screen Capture trio being distributed by IBM with the
Professional Developers Kit CD-ROM.  Currently, he works for Cheyenne Software
in Roslyn, New York and resides in Bellerose, New York with his wife Lisa.

Larry can be reached electronically via the Internet at [e-mail].

Contributors - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 8.2. Carsten Whimster ΓòÉΓòÉΓòÉ

Carsten Whimster

 Carsten is an undergraduate Computer Science student at the University of
Waterloo, and an huge OS/2 enthusiast as of OS/2 2.0.  He is currently in his
third year, taking operating system, language, and compiler courses whenever
possible.  This summer and fall he is working at the University of Waterloo as
a tutor (course assistant) for CS241, an introductory course to compilers.  He
is a TEAM-OS/2 member, and tries to keep up with several OS/2 groups on the
Internet.

 Carsten is a beginning OS/2 PM programmer with a few projects on the go, and
many more in his head.  He uses Watcom C/C++ 9.5, Watcom VX-REXX 2.0b, and
occasionally emx08h with gcc 2.5.7.  He is currently awaiting Watcom C/C++
10.0's impending arrival with bated breath.

You may reach Carsten...

...via email:

[e-mail]  - Internet

gopher://descartes.math.uwaterloo.ca:70/h0/mathSOC/.csc/.www/.bcrwhimster/homepage.html
- Mosaic homepage

...via snail mail:

Carsten Whimster
319 Erb Street West, 3rd floor
Waterloo, Ontario
Canada
N2L 1W4

 Contributors - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 8.3. Gordon Zeglinski ΓòÉΓòÉΓòÉ

Gordon Zeglinski

Gordon Zeglinski is a freelance programmer/consultant who received his Master's
degree in Mechanical Engineering with a thesis on C++ sparse matrix objects.
He has been programming in C++ for 6 years and also has a strong background in
FORTRAN.  He started developing OS/2 applications with version 2.0 .

His current projects include a client/server communications program that
utilitizes OS/2's features which has entered beta testing.  Additionally, he is
involved in the development of a "real-time" automated vehicle based on OS/2
and using C++ in which he does device driver development and designs the
applications that comprise the control logic and user interface.

He can be reached via the Internet at [e-mail].

Contributors - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 8.4. Network distributors ΓòÉΓòÉΓòÉ

Network Distributors

These people are part of our distribution system to provide EDM/2 on networks
other than the Internet.  Their help to provide access to this magazine for
others is voluntary and we appreciate them a lot!

o Paul Hethmon ([e-mail]) - Compuserve
o Gess Shankar ([e-mail]) - Internet
o David Singer ([e-mail]) - IBM Internal
o Andre Asselin (ASSELIN AT RALVM12) - IBM Internal

If you would like to become a "network distributor", be sure to contact the
editors so that we can give you the credit you deserve!

Contributors - EDM/2 - July 1994 - Volume 2, Issue 7


ΓòÉΓòÉΓòÉ 9. How Do I Get EDM/2? ΓòÉΓòÉΓòÉ

How Do I Get EDM/2?

EDM/2 can be obtained in any of the following ways:

On the Internet

o All back issues are available via anonymous FTP from the following sites:

   - ftp.cdrom.com in the /pub/os2/2_x/program/newsltr directory.
   - ftp.luth.se in the /pub/os2/programming/newsletter directory.
   - generalhq.pc.cc.cmu.edu

o The EDM/2 mailing list.  Send an empty message to [e-mail] to
  receive a file containing (among other things) instructions for subscribing
  to EDM/2.  This is a UUCP connection, so be patient please.
o IBM's external gopher/WWW server in Almaden. The address is
  index.almaden.ibm.com and it is in the "Non-IBM-Originated" submenu of the
  "OS/2 Information" menu; the URL is
  "gopher://index.almaden.ibm.com/1nonibm/os2nonib.70".

On Compuserve

All back issues are available in the OS/2 Developers Forum 2.

IBM Internal

o IBM's internal gopher/WWW server in Almaden. The address is
  n6tfx.almaden.ibm.com and it is in the "Non-IBM-Originated Files" menu; the
  URL is "gopher://n6tfx.almaden.ibm.com/1!!nonibm/nonibm.70".
o IBM's REQUEST command on all internal VM systems.  Enter the VM command
  REQUEST LIST FROM ASSELIN AT RALVM12 and a list of the requestable packages
  will be sent to you; in this list are the names of the packages containing
  the EDM/2 issues.

How do I Get EDM/2? - EDM/2 - July 1994 - Volume 2, Issue 7