ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / MAGAZINE / MISC / CNEWS014.ZIP / CNEWS014.DOC next >

Wrap

Text File | 1989-02-22 | 48.3 KB | 1,521 lines

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