The WiZ WORX IGES Source Library (WISL, pronounced "whistle") provides an application programming interface (API) for IGES files. Routines are available to both read and write IGES files. However, any manipulation of the IGES file is up to the user.
Each IGES entity has its own routines for reading (GETxxx), writing (PUTxxx), printing (LSTxxx), drawing (DRAWxxx) and memory management (FRExxx). The 'xxx' indicates an IGES Entity Type Number. These are 'mid-level' routines. Users generally call the 'high level" routines (e.g., GETENT, PUTENT, etc.) which in turn call the mid-level routine. The user can modify the processing of defaulted data fields in the individual entity routines as appropriate. Additional sets of routines are used internally but the user does not have to deal with these.
By combining the different routines the user can create a number of different types of programs. The WIZ WORX shareware programs (IGESDRAW, IGESPEEK, etc.) are produced using WISL. Source code is provided for each of these utilities.
The code is fairly basic C. It was originally developed and tested on a variety of machines, but support is currently provided only for IBM MS/DOS (and really only for the MS C compiler). There are conditional compilation statements in the code for VAX and Sun environments. Support is now available in a limited fashion for Microsoft Windows. By using Visual C++ for Windows and the QuickWin library character-based applications can be created.
WISL is shipped in compressed format on a single diskette. Once expanded and compiled it consumes 5.7 megabytes of disk space. However 2 megabytes are used for sample IGES. Also this includes the library, object and .ZIP files. The object and .ZIP files can be deleted saving over a megabyte.
One of the biggest advantages of WISL is that it was obviously written by a very experienced C programmer. One of the biggest disadvantages of WISL is that it was obviously written by a very experienced C programmer. The code is tight and takes good advantage of C. On the other hand it is poorly commented, makes use of numerous advanced C techniques and tricks and is hard to follow. Depending on your ability to read other peoples esoteric C code, this may be considered an advantage or disadvantage.
There is no documentation that accompanies WISL. Unfortunately a great deal of documentation is needed. The layout of the library is very fragmented and not immediately obvious. The code is very tight, but also very difficult to decipher. The data structures are very long and involved. The only sample code is that for the WIZ WORX utilities. Useful code to be sure, but deciphering an application is not the best way to learn an API. This results in a VERY sharp learning curve. However free consultation is provided by WIZ WORX. They were always able to answer the questions over the phone. Bug fixes and enhancements can usually be provided on disk by overnight express mail, or electronically by Compuserve.
WISL is not for the IGES novice. A great deal of IGES experience is needed to decipher the data structures that are used. While they provide complete control over the IGES entities they would be indecipherable without a great deal of IGES experience. Even experienced users must have a copy of the IGES specification at their elbow (included with the purchase if you don't have one already), because the data structures use the same mnemonics for the field names as are used in the entity definitions in the specification, (e.g., DENOTE, DEARRW, DEWIT1, etc.)
Each parameter is represented by not one but two numbers. The first gives the value of the parameter and the second signifies whether the parameter is defaulted or not. This is not immediately obvious and is easy to forget, resulting in bugs that are very hard to catch.
When using Addent to create entities (the normal method) WISL creates IGES files from the bottom-up IGES. In other words all children are output before their parent. This makes for nicely organized IGES files that it are ideal for postprocessors that require subfigure definitions (308, 320) appear in a file before the instances (408, 420). However some IGES-IN processors cannot handle files in this order. For instance CADKEY requires Drawings (404) to precede the elements that are on the drawing, but WISL puts the Drawing entity after the elements. This can necessitate a great deal of effort to rearrange the file. On the other hand, the alternative (putting each entity into the IGES file individually) would require keeping track of all of the pointers, etc (a chore that would normally be handled for you).
WISL provides direct support for the new AutoCAD implementor defined entities. This can be very useful in writing AutoCAD-specific IGES flavoring software. Other implementor defined entities can be read and written using WISL, but errors may occur because it cannot tell which of the integer fields in the PD section were DE pointers that should have been corrected.
WISL was created by Dennette Harrod, Jr. Mr. Harrod was the IGES Project Manager for over two years and is one of the leading IGES experts. IGESDRAW was used for illustrations in the IGES Specification document from Version 5 on.
WISL was developed as a testbed for new (grey-page) IGES entities and, as a result, it stays very current with changes, or even proposed changes, to the standard. WISL is fully compatible with IGES Version 5.2. It does not include geometric manipulation routines, such as algorithms to convert parametric splines and surfaces to NURB representations.
After a recent price increase WISL licenses are available for $5,000. This includes source code and on-phone consultation. This is much less than most other commercial libraries, but then much more of the burden is placed on the user.
WiZ WORX can be reached at 202-541-9434.
Last update: 2013-10-05 by Dennette@WiZ-WORX.com