OS/2 Shareware BBS: 10 Tools/10-Tools.zip/mnth0106.zip/Timur/vol1n6.txt

Text File | 1994-03-25 | 7KB | 141 lines

The Parlance of Squares

I love writing this column.  Not only do I look forward to
actually playing this game once it's done, but I like
contributing to something in which I strongly believe, and I
really do believe that OS/2 is the wave of the future.
Although the OS/2 community is currently small enough for one
individual to make an impact, we all know that this great
operating system will soon conquer the PC world and leave
Windows smoldering in the dirt.

Time constraints prevented me from adding as much as I
promised last month.  The only new enhancements you will find
are the implementation of dialog boxes for the "Map" menu
items.  Do not underestimate the amount of work required to
support these features, however.  A whole module was added
for the load and save routines.  The basic skeleton of the
code comes from Petzold's book, an antiquated yet still
valuable resource.

The dialog boxes themselves are created with the Dialog Box
Editor that comes with the tool kit.  The editor creates a
.dlg, a .res, and a .h file.  The .dlg file contains the
resource script commands that define the dialog boxes.  The
.res file is a compiled version of the .dlg file.

There are a few things that should be kept in mind.  First,
do not include .res file as a module in the make file because
the resource compiler (rc) cannot combine individual
resources.  Every time rc links a resource file into the
executable, it replaces the existing resources with those in
the .res file.  If you want to include several types of
resources, then you must create a master resource script file
which contains "rcinclude" statements.  This process will
create a single .res file containing all your resources.

Second, beware of errors in the online help for the tool kit.
The only way to be certain of the information is to check the
header files.  An example is the structure definition for
FILEFINDBUF3.  Compare this with the entry in bsedos.h and
you will see what I mean.

Last of all, double-check all the parameters when using code
designed for OS/2 1.x.  Most of the 16-bit integer parameters
are now 32 bits long.  Note that there is no speed difference
between short and long integers on a true 386/486 system,
since the 32-bit wide data bus can swallow both sizes in one
gulp.

Look at the file game.rc, which is the master resource file
for this project.  It includes the dialog.dlg file that the
editor creates.  Note that both files include dialog.h - the
header file also created by the dialog editor.  I am not sure
why this is necessary, but hopefully an explanation will
present itself in due time.

The dialog box for loading and saving files follows a
convention that exists in most applications.  The two
list-boxes show a list of directories and a list of files in
the current directory, and an entry field allows you to type
in a file or path name.  Selecting a file from the list-box
places that name in the entry field automatically.  Once you
have selected a file, click on "Save" to save the current map
to that file, or click on "Load" to load that file.  The
current implementation is not 100% complete.  The load and
save option should not be combined, and there is no check for
overwriting an existing file.  These changes will be
available in the next installment.

The code for controlling both list-boxes is in the file
files.c, which will eventually become a module of generic
file I/O routines.  The fill-functions for the list-boxes are
very similar.  Any existing entries are erased and the new
entries are determined by scanning the current drive and
directory.  You may notice that the list-boxes are extra
wide.  This allows most HPFS long filenames to be displayed
in their entirety.  I only wish that my other applications
worked the same way.  As with everything else in this
project, the dimensions of the dialog box can be changed with
the editor to suit your preferences.  Those of you with high
resolution monitors and tiny system fonts will probably want
to increase the size even further.

Notice that the DosFindFirst/Next functions ignore any
extended attributes.  The map files will eventually be given
a file type (a.k.a. association) that will distinguish them
from other files without needing a special extension.  The
short-term goal of this project is to bring the game up and
running as quickly as possible, so that no one has to wait
until 1994 before he can play the game.  Note that I did not
say 1993.  Sorry folks, but this thing will not be done
before Christmas.  I think by Springtime it should be
playable.

My roommate Scott and I got into a discussion over the
importance and design of a user interface.  We ended up
agreeing on almost everything, but the differences between
the programmer (me) and the user (Scott) became very
apparant.  Coming from his point of view, Scott argued that
the UI should be designed and coded at the same time as the
rest of the program.  His concern is that leaving the
interface until later will cause inconsistencies between the
interface and the application.  I had to agree with him on
this point, but I also had to mention that trying to create
both at the same time causes most programmers to bite off
more than they can chew.

Frankly, I think that attempting to fully design an
application, interface and all, before any coding is started
is a pipe dream that only works with software devoid of
creativity.  Remember, this game cannot be designed
beforehand because it is a group project.  New ideas and
changes occur constantly, so the primary goal for the present
is not to design a complete user interface, but rather a
flexible one.  What does that mean, you ask?  It means that
the application should not be designed with only one
"look-and-feel" in mind.

In other words, there is more than one way to skin a cat,
just like there is more than one way to create a playing
field.  Pull-down menus allowed me to create a map editor
which worked without wasting too much time on the code.  Had
I taken the time to create something more sophisticated, it
would have been vastly more time-consuming to modify the more
complicated code.  And that is only the short-term problem.
In the long run, we would probably end up with a user
interface which no longer suited the task at hand.
Therefore, our approach will be to formulate an interface
which expands along with each new feature.

This, in a nutshell, is my philosophy on user interface
design.  I will be very happy to entertain any comments on
the subject.   Scott, by the way, is responsible for the new
icon, which is much better than the one I designed.  If
anyone thinks he or she can do a better job, feel free to
submit your creativity.

I am taking a short hiatus from this project, since I am
moving into a new apartment in August.  The next installment
will appear in the November issue.  This delay will also give
my readers a chance to catch up and respond.