Category : C Source Code
Archive   : CNEWS014.ZIP
Filename : CNEWS014.DOC

C NEWS Vol. 2 Issue 14 February 20, 1988


*-------------------------------------------------------------*
| C NEWS - International C Electronic Newsletter/Journal |
| "Dedicated to the Art of C Programming" |
| |
| Founded 12/27/87 |
*-------------------------------------------------------------*


Table of Contents

The Heap: Messages from the Editor ..........................1
by Barry Lynch
Book Review: Advanced TurboC ................................3
by Richard Hendricks
Beginner's Corner: The Beginning ............................5
by Wayne Dernoncourt
AWK: An Introduction Part II . ..............................11
By Dan Kozak
Interactive C Graphics: Part II ............................15
by Scott Houck
Article Submission Standards ................................19
Address's ...................................................20
Distribution Points .........................................21
User Response Form ..........................................22


C News is an Electronic Journal published by the C BBS in
Burke, VA on a monthly basis. The subject for C News is the C
programming language, as well as any derivatives like C++.

All readers are encouraged to submit articles, reviews, or
comments for submission. C News is freely distributed, but
can not be sold for a profit, or cannot have a charge assessed
to cover distribution costs. To do so is in direct violation
of the License agreement. Copies of which are available from
the C BBS. This publication is Copyrighted under U.S
Copyright Law.






















Page 1


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
THE HEAP: Messages from the Editor
=====================================================================

TABLE OF CONTENTS:

- What's in this issue of C News
- Postcards wanted

[WHAT'S IN THIS ISSUE OF CNEWS?]


This issue of C News features part II of two articles that
started in the previous issue: AWK and Interactive C Graphics. Also
in this issue we start a new column by Wayne Dernoncourt for
Beginner's. This new column should assist some of the readers of C
News that are taking a look at "C" for the first time. In order for
the column to be of benefit to all, please provide us with some
feedback on the content. If something is presented that you do not
understand. Send a netmail message, a letter or log on to the BBS
and leave a message. Wayne and I will try to incorporate any
feedback received into future issues of C News.

[POSTCARDS WANTED!]


Postcards are still wanted!! Since the last issue I have
received postcards from the following individuals:

Henk Deutekom - The Netherlands
Stephan Mes - The Netherlands
Vin Locke - San Francisco, California
W.G. Thompson - Bangkok, Thailand


So the breakdown of postcards received to date is:

United States World

Virginia Montreal, Canada
New York The Netherlands
Maryland Thailand
California

[In Closing...]

I mentioned in the previous paragraph that I received a postcard
from W. (Bill) Thompson in Thailand. Bill is also the CP/M disk
librarian of the "Bangkok Computer Users Group" or BUGS. A few days
ago i received a disk in a pre-paid mailer from Bill with a request
for a few back issues of C News. I was very happy to oblige, and I
will honor similar requests from other user groups. All of the files
on the BBS are available via the post if you would like to save on
telephone bills. Either send me some diskettes with a pre-paid
mailer with a list, or I will charge you a $1(USD) a disk and postage
(surface). Either way, I am always willing to fill requests.

Also by the time that you read this, if you are a reader in "The


Page 2


C NEWS Vol. 2 Issue 14 February 20, 1988


Netherlands", I have sent 80 diskettes containing most of the files
on this BBS to Henk Wevers. (Henk's address is in the back of this
issue.)

So, I hope you enjoy this issue of C News and please send in any
concerns, questions, bug tips, reviews or whatever to the address's
listed in the back.

Regards,

Barry

















































Page 3


C NEWS Vol. 2 Issue 14 February 20, 1988


=================================================================
BOOK REVIEW: By Richard Hendricks
=================================================================

Title: Advanced Turbo C, Second Edition
Author: Herbert Schildt
ISBN Number: 0-07-881479-0
Publisher: Osborne McGraw-Hill
2600 Tenth Street
Berkeley, CA 94710

This book is an updated edition of the original Advanced Turbo
C. The primary changes to the book are in the area of Chapter 6:
GRAPHICS. According to the PREFACE, the First Edition included the
development of a small graphics subsystem, which has been replaced
with a discussion of the graphics functions provided in Turbo C
Version 1.5.

This book contains 12 chapters and 2 Appendixes. The included
subjects are: "Sorting and Searching", "Queues, Stacks, Linked
Lists, and Trees", "Dynamic Allocation", "Using System Resources",
"Interfacing with Assembly Language Routines", "Graphics",
"Statistics", "Codes and Data Compression", "Random Number Generators
and Simulations", "Expression Parsing and Evaluation", "Converting
Turbo Pascal to Turbo C", "Efficiency, Porting and Debugging", "Turbo
C's Memory Models" and "A Review of Turbo C".

Throughout the book the author includes interesting and useful
examples. I was impressed with the creativity and accuracy of the
examples. Techniques described in earlier chapters are used in latter
chapters, thus providing examples that further the topics of the
book.

I enjoyed reading this book, some good solid technical
information is supplied and I learned something from each chapter.

I did find some TYPO's in the book. Most of them were in the
GRAPHICS chapter. The author includes some tables of Predefined
Macros, that contain errors or omissions. I also found an error in
the description of the 'viewporttype' structure. The author calls the
fifth element of the structure 'clipflag' and graphics.h defines it
as 'clip'. The author's variable name is more descriptive, but Turbo
C will not accept it. Refer to your Turbo C manual or the graphics.h
header file, rather than this text, if Turbo C gives you an "Error
... Undefined symbol" for graphics related variables and Macros.















Page 4


C NEWS Vol. 2 Issue 14 February 20, 1988


I would recommend this book despite the TYPO's that I found.
The author covers the subjects quite well and the examples are
interesting and helpful. The Cover Price is $22.95 and there is a
source disk available from the author at a cost of $24.95.

Richard Hendricks
22 Maplewood Road
Tewksbury, Ma 01910

Home: (508) 851-8447
Work: (617) 594-9692
FAX : (617) 594-7765
















































Page 5


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
BEGINNER'S CORNER: by Wayne Dernoncourt
=====================================================================

*** Editor's Note: Many of you have stated in letters, postcards,
and phone calls. That a column dedicated to beginner's would
be very useful. Mr. Dernoncourt approached me with some columns
that he had written for a newsletter at his office and asked
me if I would be interested in including them in C News. I
reviewed them and decided to include his column as a regular
feature. So here are the first two columns: Oct and Nov.
Wayne and I would both appreciate feedback on the content and
any questions that you might have.

The Ed.



[PROGRAMMING]
[How to Write a Program]

So your boss has assigned you to write a new program to solve
one of his most nagging problems. Or you've heard that there is this
great new language called 'C' and you want to learn how to write
programs in it. In this space in future columns, I'm going to try to
introduce you both to the art/science of writing good programs and
possibly teaching you some of the aspects of both C.

I plan to use the Borland Turbo-C language in these discussions
whenever I present code that has to be system specific, but normally
I'll try to keep the code portable (not version/platform specific).

You have the pleasure of writing a program, sounds pretty
simple. All I do is put in some DIMENSION statements, some DO-LOOPS
and a bunch of PRINT statements and I'm done right. Wrong!!

The first step to writing a program of any size is designing the
program. If you were a new contractor and got a job to build a
house, would you start this job by first going out and buying a lot,
some lumber, nails, etc. before you found out how big the house was
supposed to be. I know I wouldn't and I'm willing to bet that you
wouldn't either.

The first thing you would do is to ask the person that you're
building this house for a couple of things:

1. How big is it going to be (number of bedrooms/baths)?

2. Is there going to be a carport/garage?

3. Do you want to line in the city, suburbs or the
country?

Questions that you really need to answer before you go out and
get land much less get the materials.

So the first step in this process is to:



Page 6


C NEWS Vol. 2 Issue 14 February 20, 1988


[1. DEFINE THE PROBLEM]

Define the problem, clearly state what your objective is.
Define the scope of what exactly you want your program to do and what
you don't want it to do. Write out what your program is supposed to
accomplish and put it at the top of a blank of piece of paper.
Beneath this write what sort of results that you want to come out of
this program. Generalities like, I want the correct result to appear
on the screen are insufficient. Be as specific as possible, for
example, my checkbook balance curve should be plotted on either the
CRT or the HP-7550 plotter attached to my PC. You can also put here,
what it won't do, for example, this program will not consider deficit
spending (automatic overdraft protection).

Now that you've done this very important step, you must develop
your strategy about how to solve this problem. Don't let the size of
this mountain over whelm you. The important thing is to get it down
on paper.

Your strategy to conquer this mountain is very simple, convert
this one very large mountain into a lot of small molehills. To do
this, develop what a method of how your program should run. For
example:

1. Enter data
2. Process data
3. Print results

Then sub-divide these smaller problems further into still
smaller problems. Do this by reviewing how the mechanics of how you
would go about solving this problem by hand would be done. Where do
you get all of the numbers and where do they go? Each of the
solutions to these smaller problems will become modules of the main
program.

In the past, programs where usually written as large monolithic
programs, with only a few subroutines (as compared to the number of
lines) with each sub routine having many side effects.

All of this may sound very trivial, but it isn't. The flow of
the data around your program is extremely important. The side
effects mentioned in the previous paragraph for example might include
modifying a variable that although making the program more efficient,
makes the maintenance on that program much more difficult. Almost all
programs require maintenance at one time or another, they usually
start out as "Just a small change here and it will be perfect." or
something equally innocent. Maintenance right now consumes
approximately 50-80% as programs mature and age. Yours, no doubt,
will follow that same curve, unless you take steps now to slow this.

Now, that you've read almost a page and a half, I bet you're
asking when are we going to see some actual coding. I hate to admit
it, but you won't for this first installment. Studies have been done
that reveal that the better planned a system is, the less time is
spent on debugging and maintaining a program. This is why I'm going
to emphasize to the degree I am the planning aspect right now!




Page 7


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
BEGINNER'S CORNER: by Wayne Dernoncourt (Part II)
=====================================================================

In the October column we discussed and stressed the importance
of designing the program so that it did what you wanted it to do.
You did this by writing down at the top of a blank piece paper
exactly what the program was going to do. You then sub-divided this
larger problem into smaller, easier to solve problem, writing down
descriptions of how you were going to solve this problem. You only
want to go one level down. For example:

This program is to find the mean (average) of a series of
numbers. The numbers will be read in from the keyboard (with
each value followed by a carriage return) and printed on the
screen. Enter -1 when finished.

1. Declare all variables needed and initialize them to
zero.

2. Get 4 numbers from the keyboard (to simplify the
problem, we will initially use numbers hardcoded into the
program). As this column progresses, these simplifications
will be removed.

3. Perform needed computations

4. Print results

5. Exit the program


Give each of these sub-problems descriptive titles, such as
get_data, compute, print_results & exit. Note that each of these
titles are lower-case and use underscores in place of spaces. The C
language distinguishes between upper and lower case. The C language
doesn't allow spaces to be embedded in a variable name, use
underscores instead. Variables can be up to 30 characters long.
Also put these individual steps on separate sheets of paper. These
individual steps will become the basis for the needed functions. The
initialization section won't be a separate function for reasons
explained in a later installment of this column.

I promised in the last column that we would start writing a
program. Get into your favorite editor. If it is Wordstar, use the
N (non-document) mode. If you're using Turbo-C, the command would
be:

TC filename

This will bring up the Turbo-C integrated development environment
with a built-in editor and compiler.

Now copy what you have written onto the screen and enclose it in
a pair of comment delimiters "/* ..... */", or:

/* This is Example 2A */
/* This program is to find the mean (average) of a series of


Page 8




C NEWS Vol. 2 Issue 14 February 20, 1988


numbers. The numbers are read in from the keyboard and printed
on the screen. Enter -1 when finished */

The important things about the comment delimiters is that they
must match and they can't be nested. For example:

/* This is Example 2B */
/* /* This is illegal and should be flagged as an error by the
compiler you are using!! */ */

Also the Prime C compiler has a problem with extending a comment
across lines as shown in the correct example above. Example 2A is
allowed according to the draft ANSI standard and also in Microsoft C,
Turbo C and VAX/VMS C. Put each function into its own file and call
that file by the title that you gave it. Append the file type of C
to each file. This indicates that it is a C-language source file.
Using the example program that we're discussing, we would have the
following files:

GET_DATA.C
COMPUTE.C
PRINT_RESULTS.C
EXIT.C

Also in each of the sub-files, put the title of your function
and a pair of parentheses after the comment that describes what the
function is for. For example with the first function you would have
in a file called GET_DATA.C:

/* 2. Get 4 numbers from the keyboard. To simplify the problem,
we will initially use numbers hardcoded into the program.
As this column progresses, these simplifications will be
removed. */

get_data()

That's the entire file as it stands, 6 lines long. You probably
noticed that after the phrase "get_data" is a pair of parentheses
with nothing in them. Parentheses is the method that data is passed
into a function. Even if no information is being passed into a
function, they still must be present. We will expand this file
shortly.

In C, all "action commands" or statements must be terminated
with a semi-colon (;). This means that comment lines don't have to
be terminated with a semi-colon and neither do function declarations
or compiler directives (discussed shortly). A function declaration
names the function. That is why I had you put the title at the top
of each file. You can have just one file with all of these functions
in it, but to help you keep the logic behind using functions, we will
keep them in separate modules and compile and debug them separately.
A statement consists of assignment operations, function calls (calls
to subroutines) or flow control elements. Compiler directives and
function declarations aren't considered statements.

Using a pair of braces /{ ... }/ can group any number of
statements into one logical statement. For example:



Page 9


C NEWS Vol. 2 Issue 14 February 20, 1988


{
In
English,
this
is
the
same.
}

as

In English, this is the same.

The reason that I bring this up is that in C, you can only have
one logical statement per function. Therefore in C, braces are used
a lot. So now our init() function looks like:


/* 2. Get 4 numbers from the keyboard. To simplify the
problem, we will initially use numbers hardcoded into the
program. As this column progresses, these
simplifications will be removed. */

get_data()
{

}

In C all variables *must* be declared before they're used,
also the case (either upper or lower) is important in C. There
are three main types of declarations:

1. int - declares integers
2. float - declares real numbers (floating point numbers)
3. char - declares character variables

Until recently (the draft ANSI standard) the variable type
int and char could be used interchangeably, and in some cases
still are. The variable names follow the same rules as the
function names do. So now our function for get_data looks like:

/* 2. Get 4 numbers from the keyboard. To simplify the
problem, we will initially use numbers hardcoded into the
program. As this column progresses, these
simplifications will be removed. */

float get_data()
{
float sum_x=0.0;

sum_x = sum_x + 1.0; /* Start here*/
sum_x = sum_x + 2.0;
sum_x = sum_x + 3.0;
sum_x = sum_x + 4.0; /* End here*/

/* Now is the time to return back to the main program. */
return(sum_x);
}


Page 10


C NEWS Vol. 2 Issue 14 February 20, 1988


The variable sum_x is initialized to zero when it is declared in
the float statement. The word float at the beginning of the function
declaration declares that the function will declare a real number.
All functions should declare what kind of value will be returned (if
any).

The operation of adding the variable sum_x to another number and
storing that back into the variable sum_x is a fairly common
occurrence. So much so that the developers of C decided that that
operation could be done just as well with what is called the
assignment operator. This replaces the four lines given above
between the comments /* Start here*/ and /* End here*/ with the code
given between the same delimiters:


/* 2. Get 4 numbers from the keyboard. To simplify the
problem, we will initially use numbers hardcoded into the

program. As this column progresses, these
simplifications will be removed. */

float get_data()
{
float sum_x=0.0;

sum_x += 1.0; /* Start here*/
sum_x += 2.0;
sum_x += 3.0;
sum_x += 4.0; /* End here*/

/* Now is the time to return back to the main program. */
return(sum_x);
}

Well that's it for this month. Next month we'll write the main
program, the remaining functions and discuss the details of compiling
and linking the program using Turbo-C.
























Page 11


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
An Introduction to AWK by Dan Kozak - Part II
=====================================================================


AWK AWK

Lest you think you're in an aviary, let me assure you: this is
the part two of the AWK article. Now I didn't know that this was a
multi-part article until I saw the first part in print (on-screen ?),
but then I got an idea . . .

Same C Time, same C channel . . .

If you remember last time you tuned in, Jim and Barry were just
starting their OpusGraf project. In part 1 of that series they gave
the design specs for the utility -- basically a graphic display of
time usage on an Opus BBS system. Now AWK doesn't have graphics
capability, but it can graph data using a histogram. So I've whipped
up a small AWK program to do the job. It doesn't include all the
features that Jim and Barry specified, but does get the job done. It
limitations are:

o only displays callers (not other BBS activity like File
Requests)
o not graphic, just a histogram of *'s
o fixed resolution (half-hour intervals)
o must specify bbs name on command line (could be run from
batch file though)
o slow (about 1 sec per 2k of log file size though actual
mileage may vary)
o no options


Since AWK writes to standard output the graph can be redirected
to a file for later display, but this is not an integral feature of
the program.

[The program]

I'm not going to say alot about the program because I feel that
part of becoming fluent in a language is learning how to read its
programs. However, here are a few things to look for:


o our basic data structure is an associative array, see how
AWK handles alot of the dirty work for us, but note how
careful we need to be about our subscripts

o those of you with the AWK book may recognize the rep
function from the histogram program there. While it is
certainly an example of good modular coding to make this a
separate function, it is noticeably less efficient. As an
exercise, incorporate it into the END block as inline
code.

o the same goes for the code to allow you to put the BBS
name on the command line -- hard code it for speed.



Page 12


C NEWS Vol. 2 Issue 14 February 20, 1988


o what would you need to change to make the resolution
variable (i.e. hour intervals or 15 minute intervals)?


[Running the program]

Those of you who aren't OPUS sysops will need a sample OPUS.LOG
file to run this on. If your friendly neighborhood sysop can't/won't
make one available (I don't see why they shouldn't since it doesn't
reveal passwords or anything like that), you can download/FREQ one
from the C BBS -- it's called OPUSSAMP.ZOO. (It was too large to
include here). You may notice that it takes 4-6 days data (depending
on traffic) before you get much of a graph -- why is this? how could
you make a more frequent graph look more impressive?

[Finis]

Well, that about covers it . . . a quick and dirty Opus usage
graph. You may have noticed this is really more of an example than a
full blown article but I'm available on the C BBS to answer any
questions or just get feedback. Rob Duff's AWK is available there
for those of you who don't already have it and actually I must
recommend it as a free AWK because the GNU Project AWK (GAWK) doesn't
seem to work very well under DOS at this time (something I'm trying
to find time to fix). Without further ado (since I've used all my
ado up), here's opusgraf.awk:


































Page 13


C NEWS Vol. 2 Issue 14 February 20, 1988


#
# opusgraf.awk - makes a histogram of Opus BBS caller usage
#

BEGIN { # get the bbs name from the command line
bbs_name = ARGV[ARGC - 1]

# then null it out so it wont be interpreted as a file
# name
ARGV[ARGC - 1] = ""

# initialize an array with entries for each half-hour
# period
for(hour = 0;hour < 24;hour++) {
hour = (length(hour) < 2) ? ("0" hour) : hour
for(min = "00";min < 60;min += 30)
humans[hour ":" min] = 0;
}
}

# we're only interested in callers
/calling/ {
# some log entries have a blank first field, so
# we have to compensate
if ($4 /:/)
fld = 4
else
fld = 3

# save the first and last dates
if (startdate == "")
startdate = $(fld - 1) " " $(fld - 2)
else
enddate = $(fld - 1) " " $(fld - 2)

# process the hour entry, remove ":" if necessary and
# pad with 0's
hour = substr($fld,1,2)
if (sub(":","",hour))
hour = (length(hour) < 2) ? ("0" hour) : hour

# process the minutes entry, rounding off at
# half-hour intervals
min = substr($fld,4,2)
if (min < 30)
min = 0
else
min = 30

# assemble the index string
timestring = hour ":" ((min == 0) ? "00" : min)

# increment the value
humans[timestring]++
}


END {


Page 14


C NEWS Vol. 2 Issue 14 February 20, 1988


# put the name of the BBS on the command line
printf("Stats for %s from %s to %sn",
bbs_name,startdate,enddate)

# generate the histogram
for(time in humans) {
printf("%sn",time,rep(humans[time],"*"))
}
}

# separate function to create string of *'s
function rep(n,s, t) {
while(n-- > 0)
t = t s
return t
}












































Page 15


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
Interactive Graphics Programming Using Turbo C -- Part 2
by Scott Houck
=====================================================================

[INTRODUCTION]

This is the second in a series of articles on interactive
graphics using Turbo C. I chose Turbo C because of its powerful
graphics package.

First, a note concerning Part 1. A reader asked what the
following comment in the source code meant: "Add egavga.bgi to
graphics.lib". By this I meant that the reader should use the
program BGIOBJ.EXE to convert the file EGAVGA.BGI to an .OBJ file.
Then use TLIB to add the object file to GRAPHICS.LIB. See the
appendix in the Reference Guide for further details.

In Part 1, I promised to present a simple paint program that
would demonstrate pull-down menus, "rubber banding" techniques, fill
patterns, and mouse cursor programming. As the program grew in
complexity, I decided not to cover pull-down menus in this article
since that is a topic that could span an entire article in itself.
The other items are included, along with a discussion of the
important issue of user input.

[HOW TO USE THE PROGRAM]

To use the program, you must have either an EGA or a VGA, and a
Microsoft-compatible mouse. When you start up the program, you are
in "paint" mode and the PAINT button is highlighted. There is a
white drawing area, and you draw by holding down the left mouse
button while moving the mouse. Lift up on the mouse button to stop
drawing.

The initial drawing color is black, and the background color is
white. A square at the bottom lefthand side of the screen shows the
current drawing color and background color status. The drawing color
is represented by the inner box, and the background color is
represented by the border. To change the drawing color, click the
left mouse button on one of the sixteen colors that stretch along the
bottom of the screen. To change the background color, click on a
color with the right button.

Under the PAINT button is the FILL button. Click on this
button, and you will be in "fill" mode. Now when you click with the
left button while inside the drawing area, the object you select will
be filled with the background color. You may choose a different fill
pattern other than the initial solid fill pattern by clicking on a
pattern box at the bottom of the screen. Be careful to click on an
enclosed area or the "paint" will overflow to other parts of the
screen.

You can erase what you've done by clicking on the ERASER
button. When you move the cursor inside the drawing area, the cursor
will change its shape from an arrow to a small rectangle. To erase,
hold down on the left mouse button and move the mouse until you are
finished. Then release the button and choose another button to


Page 16


C NEWS Vol. 2 Issue 14 February 20, 1988


continue. Choose PAINT, for example, to continue drawing.

The screen can be cleared by clicking on the CLEAR button and
then clicking on YES from the dialog box. The screen will be cleared
in the current background color and fill pattern.

LOAD and SAVE allow you to store pictures in files. The files
have a default extension of .PIC, so when you are prompted for a
filename, do not type in an extension. Since the "undo" feature is
left to the reader as an exercise, you may want to save your picture
before doing something dangerous like filling an object. The default
filename is PAINT.PIC. If you want the default, just press the ENTER
key. Otherwise, type in a new filename.

QUIT will terminate the program after confirmation. The last
two buttons show a rectangle and a line. These are the "rubberband"
figures. To draw a rectangle, for example, click on the rectangle,
then click inside the drawing area to anchor the rectangle and
continue to hold down on the left mouse button. Now move the mouse
to expand or contract the rectangle. Release the mouse button when
you are finished. The rubber line works the same way.

[PROGRAMMING CONCEPTS]

This program expands on some of the concepts presented in Part 1
of this series. The same mouse functions are used, and pick
correlation is still required to determine where the user has clicked
the mouse. The colors and fill patterns are drawn at the botton of
the screen. When the user clicks on one of the color boxes with the
left button, a call to setcolor() is made. If the right button was
used, the background color is set in the variable fillColor. Then a
call to setfillstyle() is used with this color.

Painting is very simple to program. It is accomplished in the
DoPaint() function. I simply loop while the button is down, making
calls to lineto() from the old position to the new position. In
order to avoid flicker of the mouse cursor, I only call lineto() if
the cursor position has changed.

Filling an area is also fairly simple. There is a slight
complexity, however. The floodfill() function needs to know the
border color of the area to be filled. Since this is an interactive
program, I used getpixel() on the current position to get the color
of the area's interior. Then I loop, incrementing the x position
until the color changes, at which point I assume the border has been
reached. Look at the DoFill() function to see how this was done.

[MOUSE CURSORS]

I implemented the eraser as a different cursor shape. There are
other ways of implementing an eraser, but I wanted to experiment with
mouse function number 9 (Set Graphics Cursor). This function
requires an array as its argument. The array contains a bitmap of
the cursor broken down into two parts: the screen mask and the
cursor mask. There are two arrays at the beginning of the source
code. One is for the eraser, and the other is for the standard
cursor. When the "eraser cursor" moves out of the drawing area, I
restore the mouse cursor to the "standard cursor".


Page 17


C NEWS Vol. 2 Issue 14 February 20, 1988


The screen mask is used to determine whether the cursor pixel is
part of the shape or the background. The cursor mask is the shape of
the cursor itself and also determines the color of the cursor. The
mouse driver ANDs the screen mask with the bits on the screen. Then
the cursor mask is XORed with the result. This allows a lot of
flexibility in the types of cursors you can create. You can have
solid cursors or "see-through" cursors. The eraser cursor is an
example of the latter. The parts of the cursor that are
"see-through" have a 1 for the screen mask and a 0 for the cursor
mask.

[MOUSE-ON/MOUSE-OFF]

Throughout the code, you will notice that I often envelope
procedures with calls to MouseOff() and MouseOn(). This is necessary
whenever the screen is updated -- when drawing or saving the screen
image. If this is not done, the cursor gets in the way of the
updating, and in the case of a screen save, will itself be included
in the file unless specifically turned off.

[USER INPUT]

I spent quite a bit of time writing the code that would accept
an eight-character filename from the user. It is still not the
friendliest prompt, but the code will give you an idea of some of the
complexities involved in prompting for input in a graphics program.

First of all, I needed an area for input. I decided to use a
pop-up box, implemented with getimage() and putimage(). The high
level routine PromptForFile() gets the filename. It calls a lower
level routine GetString(), which in turn calls GetChar(). GetChar()
only gets one character but doesn't return until it gets a "legal"
character. It can also be used to get function keys if you specify
the scan codes it can accept. GetString() loops until the user
presses the ENTER key. Each keystroke is processed. It checks for a
backspace, the Escape key, an optional function key, and "legal"
keys. A default value is first displayed. If the user presses the
Escape key, the default reappears. If function keys need to be
processed, they are handled by passing a pointer to a key handler
routine.

The input was a lot of work, but it is still rudimentary. There
is no text-like cursor in the prompt box. This would have to be
programmed in. Also, the DoLoad() and DoSave() functions should be
enhanced to tell the user if a file that he wants to load doesn't
exist (it just beeps for now), or to ask for confirmation when the
user is about to overwrite a file when saving.

[RUBBERBANDING TECHNIQUES]

The rubberbanding technique is really quite simple too. The
trick is to use the XOR write mode. Drawing twice in XOR mode causes
the line to be erased and the background restored. Unfortunately,
the Turbo C manual plainly states that the setwritemode() function
does not yet work with ellipses, so I did not implement a rubber
ellipse.

[ENHANCEMENTS]


Page 18


C NEWS Vol. 2 Issue 14 February 20, 1988


If you are interested in Turbo C and its graphics package, try
experimenting with the program. Try to add some new features. One
good feature would be to include an "undo". To do this, you could
periodically make calls to getimage() to save the current screen and
putimage() to restore it when the user chooses the undo feature. You
might also want to experiment with different cursors. Try making a
special paintbrush cursor when you are in paint mode, or a paint
roller when you are in fill mode.




















































Page 19


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
ARTICLE SUBMISSION STANDARDS AND ADDRESSES
=====================================================================

As I have repeatedly stated in this newsletter and previous
issues, I would like to see user-submitted articles, reviews or
questions. Listed below are the standards that should be followed to
make my job easier as an editor.


- Articles should be submitted in a ASCII non-formatted
file. (Margins 0-65 PLEASE)

- If the article include code fragments as examples. Then
you can include the entire source file if you like for
inclusion with the newsletter.

- Book or magazine reviews should follow the same format,
that is outlined in this issue. The publisher, author,
title, and ISBN number are a must.

- Compiler/and or product reviews, should include the
version number and manufacture. If possible, reviews
should include a sample program with benchmarks.

If you have any questions you can contact me at the address's
included on the next page.

































Page 20


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
HOW YOU CAN REACH THE AUTHORS OF C NEWS
=====================================================================

ADDRESSES

The C BBS is located at:

C BBS
% BCL Limited
P.O. Box 9162
McLean VA, 22102


or you can send netmail to:


1:109/307

or MCI Mail to: BCL Limited








































Page 21


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
DISTRIBUTION POINTS
=====================================================================


Board Name Number Net/Node Sysop


*** United States ***

C BBS (703) 644-6478 1:109/307 Barry Lynch
Burke, VA


Eastern C Board (201) 247-6748 1:107/335 Todd Lehr

Exec-PC (414) 964-5160 .. Bob Mahoney
Milwaukee, WI

TAMIAMI (813) 793-2392 Gerhard Barth
Naples, FL

Sound of Music (516) 536-8723(2400) Paul Waldinger
(516) 536-6819(9600 Hayes V)

*** CANADA ***

Another BBS System (416) 465-7752 1:148/208 Mark Bowman
Toronto, Canada

*** EUROPE ***

Fido_N1_1 31-8350-37156 2:500/1 Henk Wevers
The Netherlands

DUBBS BBS 353-1-885634 n/a Stephen Kearon
Dublin, Ireland


*** AUSTRALIA ***

Sentry BBS 02-428-4687 ... Trev Roydhouse
(300-2400) Non-Mail Times
(300-19,200) Mail Hour (Trailblazer)
















Page 22


C NEWS Vol. 2 Issue 14 February 20, 1988


=====================================================================
USER RESPONSE FORM
=====================================================================

This form will be included as a regular feature in all
future issues of C NEWS.



What did you think of the content of this Issue? _____________


_______________________________________________________________


What improvements can you think of that would make C News a
better tool for the C Community?

_______________________________________________________________


_______________________________________________________________



What is your favorite section or sections? ___________________


_______________________________________________________________



What don't you like about C News? ____________________________


_______________________________________________________________



Additional Comments: _________________________________________


_______________________________________________________________


_______________________________________________________________


_______________________________________________________________











Page 23