旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � DB/C Newsletter � � March 1993 � 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Editor's Notes DB/C 8.0 finally shipped in February 1993. It was a long time coming, but well worth the wait. Many of the questions being asked about DB/C 8.0 concern the Report Writer and GUI programming. An in depth discussion about the Report Writer will be contained in next month's DB/C Newsletter. There are many aspects to GUI programming, but in the data processing world image storage and retrieval are a part of many GUI applications. When discussing image storage and retrieval, methods of compression methods and file compatibilities are usually the first topics to be explored. This month's article about TIFF files may help you to understand a little bit more about this arcane area of knowledge. This month's other article is about the Extended Verbs that are new to DB/C. Extended Verbs have many useful applications. I recommend that you explore their utility in your environment. Good reading. DNW The Library of Extended Verbs One of the most useful new features of DB/C 8.0 is the Library of Extended Verbs that is described in the second half of the Fast Programming manual. A common misconception is that these user-defined verbs are only useful when used in conjunction with the Data Dictionary, Screen Painter and Program Generator that make up the rest of Fast Programming. This is not the case - the Library of Extended verbs is very useful by itself. Code reusability has been an important concern of applications developers for the last twenty years. The primary benefit of object-oriented programming is code reusability. Even before the term "object-oriented" became popular, libraries of functions and routines were very popular. Code libraries allowed programmers to take advantage of completely debugged code, at a fraction of the cost in time and money. The advent of user-defined verbs in DB/C 7.0 added to DB/C the ability to implement sophisticated code reuse. The number of verbs in the DB/C language has grown with each new release. Many other potential verbs have not been included with each new release because of various issues. The total number of verbs in DB/C is now over 200, so one of the limiting factors is the task of just remembering all the verbs. Some of the potential verbs were too complicated, others duplicated part of the functionality of existing verbs, and others might not be useful to some because they contained or did not contain a certain feature. User-defined verbs were created to allow programmers to create their own verbs that were tailored to their needs. The Library of Extended verbs provides a pre-built set of user-defined verbs that provide functionality in two areas: user interface and file handling. For example, the MENU extended verb handles all of the KEYIN and DISPLAY actions necessary to provide a pop-up menu, with full arrow key, color display, and subwindow restoration capability. Similarly, the FWRITE extended verb provides for writing of the record, for construction of primary and secondary keys, and for writing of all indexes, both ISAM and AIM. Here is an example of the use of the MENU and ERROR extended verbs: INCLUDE EXTVERBS LOADMOD "EXTVERB1" DISPLAY *ES; MENU TITLE="Example Menu": ITEM="First item", routine=first: ITEM="Second item", routine=second: ITEM="Third item", routine=third STOP FIRST LROUTINE ERROR TEXT="First item was selected" RETURN ENDROUTINE SECOND LROUTINE ERROR TEXT="Second item was selected" RETURN ENDROUTINE THIRD LROUTINE ERROR TEXT="Third item was selected" RETURN ENDROUTINE In the example, the MENU extended verb displays a centered box that has a title and three lines. When the ENTER key is pressed, the routine associated with the currently selected line is called. The line that is selected may be altered by using the arrow keys, the HOME and END key or by pressing the key of the first letter of each line in the menu. When the ESCAPE key is pressed, the MENU statement terminates, the screen area underneath it is restored and the STOP statement following the MENU statement is executed. In the example, the ERROR extended verb displays a centered box with the message specified and instructions to press ENTER to continue. When ENTER is pressed, the error box is removed, the screen area underneath it is restored and the statement following the ERROR statement is executed. The record list and file list that are used in the FOPEN, FREAD, FWRITE, etc. extended verbs may be created by hand or by the file definition generator in Fast Programming. This is the only aspect of the Extended Verbs that is linked with Fast Programming. In all other respects, the Extended Verbs have no link to Fast Programming. The .dbc object files that make up the Extended Verbs are EXTVERB1.DBC, EXTVERB2.DBC, EXTVERB3.DBC and EXTVERB4.DBC. These files are contained in the FP.DBL library that is on the DB/C 8.0 distribution media. The source include file that contains the verb prototypes for the Extended Verbs is EXTVERBS.TXT. This file is also found on the DB/C 8.0 distribution media. The source files for the Extended Verbs may be found in the RWFP File Area of the DB/C Bulletin Board, along with the source to Fast Programming and to the Report Writer. It is important to recognize that the Extended Verbs are in what is essentially their first release. Future releases will contain many more user-defined verbs, along with enhancements to the existing Extended Verbs. TIFF Files and DB/C DB/C 8.0 provides support for programming for Graphical User Interface (GUI) environments. An important aspect of GUI programming is dealing with images. DB/C makes dealing with images easy by providing a first-class variable type called an image variable. Several verbs manipulate image variables including DRAW, PRINT, LOAD and STORE. Here is a sample program that draws two boxes into an image variable and then prints the image: IMG IMAGE H=900, V=900, COLORBITS=1 DRAW IMG; COLOR=*WHITE, ERASE, COLOR=*BLACK: P=1:1, BOX=900:900, P=300:300, BOX=600:600 SPLOPEN "DEFAULT(300)" PRINT IMG SPLCLOSE The variable IMG is the image variable that is modified by the DRAW verb and is printed with the PRINT verb. The size of the image variable is 900 pixels by 900 pixels. Each pixel contains 1 bit of color information which means it is only capable of storing a black or white pixel value. The DRAW verb draws two boxes, one at the perimeter of the 900 by 900 pixel image variable, and one inside it. The print resolution is specified at 300 dots per inch in the SPLOPEN statement, so that the outer box will consume 3 inches by 3 inches on the printed page. DB/C provides the ability to load and store images from and to TIFF files. Here is the code to load an image from a TIFF file into an image variable: IMG IMAGE H=2550, V=3300, COLORBITS=1 TIFF DEVICE OPEN TIFF, "file.tif" LOAD IMG FROM TIFF CLOSE TIFF Here is code to store an image into a TIFF file: IMG IMAGE H=2550, V=3300, COLORBITS=1 TIFF DEVICE PREPARE TIFF, "file.tif" DRAW IMG; COLOR=*WHITE, ERASE STORE IMG INTO TIFF CLOSE TIFF All of this is very useful, with one caveat - the DB/C LOAD verb cannot load all types of TIFF files and the DB/C STORE verb only creates certain types of TIFF file. The immediate question is: Which kind of TIFF file does DB/C support? A brief description of the TIFF standard is necessary before the we can answer the question. TIFF stands for Tagged Interchange File Format. It is a standard that was created primarily by Aldus Corporation for use with IBM PC and Apple Macintosh computers. The TIFF standard is at Revision 6.0. With each revision, many new features have been added. TIFF files are now capable of storing several different kinds of images including black and white (monochrome) images, gray scale images, palette based color images and full color images. There are literally dozens of options available for each of these different types of images. The word Tagged in the TIFF name is important in allowing the standard to grow. Each piece of information associated with an image is tagged and added to the TIFF file. The TIFF file just consists of multiple of these chunks of information, each of which is tagged. The chunks need not be in any order, because the tag identifies what each chunk contains. Because all TIFF files follow a set pattern for tagging information, new types of information can be added to a TIFF file without disturbing the format of existing information in the file. For example, a TIFF file for storing a monochrome image that is 8.5 by 11 inches and is stored as 300 dots per inch could have a TIFF file that is laid out like this: Tag: Bits Per Pixel Value: 1 Tag: Horizontal Size Value: 2550 Tag: Vertical Size Value: 3300 Tag: Compression Type Value: 1 (means none) Tag: Pixels Value: (pixel values) This information is all that is necessary to describe the image for some applications, but other applications (like one that prints the document) may need to know that the resolution is 300 dots per inch. So its easy to just add the following tags: Tag: Resolution unit of measure Value: 2 (means inches) Tag: Horizontal resolution Value: 300 Tag: Vertical resolution Value: 300 Actual TIFF files usually have 10 or more tags in them. There actually two tags that describe the pixel values. They are: Bits Per Sample and Samples Per Pixel. Together these describe the basic type of image contained in the file. Typically these values describe images that contain 1, 2, 4, 8, 15 or 24 bits per pixel, but any other (even slightly) reasonable value is also allowed. The compression type tag has 7 values that correspond with the following types of compression: none, PackBits, CCITT Group 3 1D, CCITT Group 3 2D, CCITT Group 4, LZW and JPEG. With some types of compression, there are additional tags that describes options associated with each type of compression. Some types of compression are recommended for monochrome images, and other types of compression are recommended for color images. DB/C 8.0 was first shipped in February, 1993. The Windows and Macintosh version of DB/C provide limited ability to read and write TIFF files. Here is a summary: To write the TIFF file with the STORE statement, if the image variable is COLORBITS = 1, then PackBits compression is used if the image variable is COLORBITS > 1, then no compression is used To read a TIFF file with the LOAD statement, if the image variable is COLORBITS = 1, then only TIFF files that have 1 bit per pixel are readable, and only no compression or PackBits compression is allowed if the image variable is COLORBITS > 1, then only TIFF files that have the same number of bits per pixel or fewer bits per pixel, but not 1 bit per pixel are readable, but only if compression is none or LZW, and if the compression type is LZW, then no differencing predictor is allowed DB/C 8.0 will be enhanced to support a wider array of TIFF file options than it currently supports. DB/C Class Schedule The next DB/C class is tentatively scheduled for June 7-10, 1993. As always, it will be held in the Oak Brook, Illinois office of Subject, Wills & Company. For more information, contact Judi Tamkevic at (708) 572-0240.