This describes an older ST-Developer release (2000). You can find the details for the latest release here
The ST-Developer v8 release contains many exciting new features. Highlights include the ST-Viewer geometry viewer, a new EXPRESS compiler with better class generation and output controls, faster programming libraries, and better AP conformance checking including a specialized AP-214 checker.
|Platform||Operating System||Supported C++ Compilers|
|DEC Alpha/AXP||DEC UNIX v4.0||DEC C++ v5.3, GCC v2.7-96q1|
|HP PA-RISC||HP-UX v10.20||HP Cfront C++ with and w/o +eh,
HP ANSI C++
|IBM PowerPC||AIX 4.x||IBM CSet/xlC|
|Intel x86||Linux 2.2
|Intel x86||Windows NT v4.0 Windows 95/98||Visual C++ v6.0 with /ST, /MT, and /MD options|
|Silicon Graphics||IRIX v6.x||SGI C++ default and -n32|
|Sun SPARC||Solaris v2.x||Sun C++ v4.x, GCC v2.7.2|
|Sun SPARC||Solaris v7||Sun C++ v4.2|
ST-Developer for Windows now includes the ST-Viewer geometry visualization tool to help view, analyze and debug STEP product data. ST-Viewer displays product identification information, assembly structure information and 3D geometry information. You can annotate models and send them to other users. Visualizations of solids and wire frame models can be cut and paste into other tools and printed.
ST-Viewer reads many kinds of STEP files and generates visualizations for a product model with transformations, colors, light sources, and text annotations. The images produced by ST-Viewer can be translated into the Virtual Reality Modeling Language (VRML) and distributed over the Web.
ST-Developer now includes an OLE/COM Automation interface for ST-Viewer. Application programmers can use this to create applications that use ST-Viewer to highlight or pick the geometry or assembly structure of a product. Run time licenses are available for distributing ST-Viewer with your applications.
Applications can control ST-Viewer using Automation (formerly known as OLE Automation). They can display/select objects in a STEP model, move the viewer's camera and obtain an object's dimensions (e.g. edge length, or radius for a circular edge). The external application can also receive events from the viewer when the user selects objects in the viewer manually.
Automation lets you control an application's objects from outside the application. The application exposes a COM interface with methods and properties. These methods and properties are accessible to the your client, and the ST-Viewer becomes an automation server. The interfaces are described in ODL and presented to the client in the form of type library file. Development tools such as Microsoft Visual Studio wizards can then import the type library and generate code for the automation client. The automation client can be written in many languages, including Microsoft Visual Basic, Visual C++, and Visual J++.
The ST-Viewer OLE Automation Reference Manual describes how to work with this interface in detail. The ST-Developer demos directory contains driver program examples that control ST-Viewer and receives its events. The examples are written in Visual C++ and Visual Basic. These programs are distributed as Microsoft Visual Studio projects and include full source code.
The Windows NT/9x/2000 ST-Developer control panel has been completely redesigned to be easier to use. The new control panel is resizable, which should make it easier to monitor the output of your tools. The toolbar can also be extended, so ST-Developer "plug-ins" and future updates can add tools to the control panel.
The previous release contained two versions of the AP Conformance tool ( apconform / apconform_v2 ) and the STEP Conformance Editor ( stepedit / stepedit_v2 ). In this release, we have moved over to a single set of tools based on our latest and most advanced EXPRESS interpreter.
The new AP-214 Conformance Checking Tool is a fast alternative to the general EXPRESS interpreter-based apconform . Like our AP-203 checker, the AP-214 is faster than apconform , but it is specific to AP-214 data only. The AP-214 checker is built using early-bound C++ and is optimized for speed using such techniques as pre-computing USEDIN/INVERSE references between entity instances.
Earlier ST-Developer releases contained "basic" and "advanced" versions of the EXPRESS compiler. As of the v8 release, these have been merged into this single unified compiler that has all of the checking and output options of both.
The unified compiler is called expfront, and it can do extensive parse and type checking on such a model. In previous releases, many of these features were provided by the expxfront "advanced" compiler, but have now been folded into one compiler.
The new compiler can produce the following outputs:
- C++ class code which can be used for objects having these data structures.
- HTML and other formatted text from the EXPRESS definitions.
- Compiled data structure definitions, that application programs use to read and write STEP Part 21 files.
- EXPRESS parse data and data-dictionary information for the SDAI EXPRESS interpreter and AP conformance checking tool.
There have been many improvements to the C++ class generation and working set control files. These are described below.
In addition to "long-form" AP schemas, the new compiler can handle "short-form" schemas and can search a repository of pre-compiled schemas for the definitions. This allows the entire library of STEP Integrated Resources to be pre-compiled and used whenever a STEP short-form schema is compiled. These improvements also make compilation of PLIB and MARISTEP schemas much more robust.
Error checking has also been improved, particularly for assignment compatibility and operator/operand compatibility. The compiler can now predict possible results from an expression at runtime and point out violations. EXPRESS errors are always flagged, but warnings can be limited using options. There have also been some improvements in the checking of TYPEOF, ROLESOF, and USEDIN opertions, especially intersections with aggregates of strings.
The generated C++ classes should now compile faster than previous versions because include directives have been changed to minimize the amount of file system access that the compiler must make.
The compiler now puts the generated code for aggregates (Lists, Sets, etc.) in the same file as their base types, so you will not see any separate files for them. For example, given an entity person, and a schema that also uses list of person and set of person. Now the compiler will generate two files: person.h and person.cxx that contain the definitions for person, ListOfperson, and SetOfperson. In addition, you can generate extra aggregates using the working set.
person.h NEW BEHAVIOR -- everything in one file person.cxx person.h OLD BEHAVIOR -- aggregates in separate files person.cxx ListOfperson.h ListOfperson.cxx SetOfperson.h SetOfperson.cxx
Earlier versions put each definition into separate files, which meant more files to manage and longer compile times. This improvement should help simplify your projects a bit and improve your build times. If you have some makefiles or project files from earlier projects, you may need to adjust them.
If you need the old behavior, you can specify -aggfiles on the compiler command line. Aggregates of built-in types, such as nested lists of integers, strings, and reals, have no "base" file to go with, so they are still output to separate files.
The code generator now has several levels of checking for name conflicts. By default, it checks for attributes that have the same name as their underlying type, but more extensive checking can be done.
The working sets now recognize more options to give you better control over your class generation.
Schemas can be called out in the workingset file using the special "SCHEMA" keyword, then the name of the schema. Schemas can called out with two new directives, -all and -none, to control what definitions are generated.
By default, only definitions listed in the control file are generated. If the control file contains only ANDOR entries, all definitions are generated. Putting in a schema entry with the -all directive forces generation of all definitions for the schema. The -none directive stops generation of any definitions for the schema.
SCHEMA config_control_design -all SCHEMA config_control_design -none
Entities are usually listed by name, but we have also added the optional keyword "ENTITY" to identify entries. It is not required, but it might make your working set file clearer at times.
The compiler back-ends are now much better about dependency checking, so you only need to include entity definitions in your working set. It is no longer necessary to list enumerations and select types.
Enumerations are always generated, as well as any primitive types, select types referenced by the marked definitions, and aggregates of marked definitions that are used by the schema.
In addition, you can now use the -aggs directive to force the back-ends to generate extra aggregate definitions for a base type. The -aggs argument indicates the aggregate types using the first letter of the aggregate style. For example "L" indicates a list, "B" indicates a bag, "LL" is a nested list of list of the base type, and so on. The argument is not case sensitive.
For example, suppose my schema had a cartesian_point definition, but never used any aggregates. In my application, I might want to use a list of cartesian points for some temporary processing. Since the schema doesn't use a list, one would not normally be generated, but I could add the following line to my working set file:
cartesian_point -aggs l
This would force the compiler to generate a ListOfcartesian_point class for me. Remember that, by default, with a working set file, the compiler generates only those classes listed in the file. I might want to use the schema -all option if I wasn't using a subset of classes. This would force the compiler to generate all of the other classes in addition to cartesian point:
SCHEMA my_schema_name -all <-- generate all classes in schema cartesian_point -aggs l <-- also generate the extra list
If you need to list several aggregates, separate them with semicolons. The examples below force the generation of list, set, bag, array, and list of lists of cartesian point. All three entries are equivalent.
cartesian_point -aggs l;s;b;a;ll cartesian_point -aggs L;S;B;A;LL ENTITY cartesian_point -aggs L;S;B;A;LL
ST-Developer v8 includes a number of improvements in the SDAI C binding. In addition to a few bug fixes, the SDAI library now provides a more convenient interface for manipulating SELECT types, and a few extension functions for handling Part 21 headers and entity ID's.
Due to changes in the EXPRESS compiler, you will need to recompile any parse data files (e.g. *_EXPX.rose) you are using.
In the v7 SDAI library, a number of aggregate manipulation functions (such as sdaiAdd()) did not correctly operate, and instead indicated an error for what should be legal operations. This bug has been corrected.
The sdaiPutAttr() and sdaiPutAttrBN() functions are now more forgiving when operating on SELECT typed attributes. In previous releases, you needed to specify a path through the tree of selects with every defined type. These rules have been significantly relaxed. If the value you are setting is an ENTITY instance, you no longer need to indicate a type path, rather the system will find one for you. In the case of primitives, you still need to provide a type path, but you only need to specify enough of the type path to identify the attribute.
When you create a new SDAI model with sdaiCreateModel(), the model will be written in the STEP Part 21 file format. In previous versions, you had to make a separate call to _sdaiSetModelFormat() to set the file format. This change only effect newly created files; any model that was read in from a file is written out in the same format that is was read in.
The SDAI library now contains functions to access and manipulate information specific to STEP Part 21 files. The _sdaiGetEntityId() function returns the #nnn Entity ID number from a Part 21 file.
int id = _sdaiGetEntityId (inst);
In addition, the _sdaiHeaderDescription() and _sdaiHeaderName() functions allow an SDAI application to manipulate the Part 21 file header information. These functions return the header information as entities defined by the following EXPRESS:
ENTITY file_description; description : LIST [1:?] OF STRING (256); implementation_level : STRING (256); END_ENTITY; ENTITY file_name; name : STRING (256); time_stamp : STRING (256); author : LIST [1:?] OF STRING (256); organization : LIST [1:?] OF STRING (256); preprocessor_version : STRING (256); originating_system : STRING (256); authorization : STRING (256); END_ENTITY;
For example, you can add the author's name of a header field with the following code:
SdaiAggr auth; SdaiInstance name; name = _sdaiHeaderName (model); sdaiGetAttrBN (name, "author", sdaiAGGR, &auth); sdaiInsertByIndex (auth, 0, sdaiSTRING, "Fred Foo");
The following list contains issues with the tools and libraries that have been resolved and closed out. The issues have been sorted by package.
Package [apconform] #5087: File browser does not recognize files with a .stp extension  Package [expfront] #5058: Bad code for defined primitive types  #5059: Bad code for types referenced from other schemas  #5060: Workingset breaks C++ keyword checking  #5061: Generate lists with entities  #5063: Compiler may not realize schema changed  #5065: Compiler requires SIZEOF to be uppercase  #5070: Weak type checking on function parameters  #5110: no check for reserved words when using workingset  #5116: generates bad code for logicals in selects  #5127: identifiers are sometimes case-sensitive  #5135: class contains bad ref to schema type header  #5138: SELECT update can fail if rose error code is set  #5140: Selects: multiple NUMBER/BOOLEAN/LOGICAL missing  #5141: Use Windows conventions on the PC platform  #5147: Windows comapatbility fixes  #5150: Selects w/bool/logical incorrect access/update fns  #5186: allow -schema to be specified multiple times  #5195: ANSI C++ breaks generated select classes  #5228: bad code for atts & entities with the same name.  Package [expg] #5043: expgedit needs to produce EPS  #5044: expgedit drag can go off side of document  #5046: expgedit zoom causes you to lose the selection  #5047: request: expgedit zoomed out navigation aid.  #5054: expgedit crashes on File->Open->Cancel.  #5114: division by zero in expg layout tool  Package [expxfront] #5144: Add nodelock code to the EXPRESS-X compiler  #5152: use standard error reporting format  #5155: expxfront can conflict with rose schema files  #5157: expxfront problems with short form maristep schema  #5211: expfront -rose: doesn't see enum change  Package [extall] #5143: extall needs to recognize all extensions  #5219: extall fails in large directories  Package [igescvt] #5210: IGES tool produces rose rather than P21  Package [keylib] #5000: License hostids come out as 7ffffff on Solaris  #5215: registry keys need to change for product  Package [mkmakefile] #5088: Bad dependencies, needs updating  Package [p21] #5002: Spurious use of external mapping?  #5104: Control/extended chars written as /X/00 by mistake  #5105: minimal whitespace and pretty-printing  #5122: Strings longer than 1024 do not parse correctly  #5130: STEP filer core dumps reading an empty file  #5131: Parser didn't handle scope export lists properly  #5156: Old DIS STEP/ENDSTEP conflicts with AP-224 entity  #5196: EIDs with high bit set come out negative  #5199: no warning issued when atts are mis-ordered  #5233: aggs of logicals clipped by agressive enforcement  Package [roselib] #5005: newDesign() should accept a filename  #5008: Arrays of doubles not working correctly  #5010: Internal mechanism for typecasts too complex  #5012: SetOfDouble core dumps on HP  #5013: BOOL conflicts with MFC and private X11 headers  #5015: Cursor/findObjects() inconsistancy  #5017: NT: ROSE_DB can't have more than one directory  #5018: Typecast problems  #5019: Segv when setting enum to null string  #5020: wasVisited mistakenly coming back true?  #5099: No def for ListOfRoseType in ROSE header files.  #5112: produce AP files with multi-AP class libs  #5113: rose_empty_trash() does not remove entire designs  #5120: BINARY has no destructor and leaks memory.  #5121: Errors storing strings longer than 1024  #5124: VMS/NT path code still has case dependancies.  #5125: STEP filer does not recognize .STP file extension  #5129: addObject core dumps on a non-persistant object  #5132: trashcan could compact nulls from aggregates  #5133: RoseStringObject test functions are misleading  #5134: putObject to non-object attribute -> core dump  #5138: SELECT update can fail if rose error code is set  #5146: Typecasting problem on SGI  #5148: RoseObject::move() may be picking up metadata  #5154: OID generation sometimes fails  #5158: Incorrect comparison of RoseTypePtrs in isa()  #5159: Shortname file should take # comments  #5161: cursor inconsistancy  #5165: RoseInterface::error_reporter() deletes user storage  #5168: mutate needs to be more sensible  #5170: emptyYourself() removes schema information  #5183: Missing RoseAtt::isXYZ functions  #5193: Dictionary hash table not properly deallocated  #5194: cursor filter typedef missing  #5195: ANSI C++ breaks generated select classes  #5197: Support unset for Part 21 files.  #5207: cross-design references broken, no oids  #5226: copy/move may have some sort of problem  #5235: On PC use _stat rather than posix stat  Package [rosetool] #5084: Segv on STEP file with empty data section.  #5090: "rose ls" no longer prints the +/- symbols  Package [sdailib] #5188: sdaidis dictionary generator must use lowercase  #5216: Itor get before a next should signal unset  Package [stdev] #5101: Need rose library compiled with HP C++ +eh flag  #5118: SGI 6.2 needs librarys built w/ and wo/ -n32 option  #5126: Developer ships with DIS shortname files  #5149: Must install font files for express-g tools to work  #5181: REQ: HP ansi c++ compiler  #5229: PC: Mystery programs not linked against registry fns  Package [stepedit] #5079: Dies when creating a design  #5083: Misspelling in error message  #5084: Segv on STEP file with empty data section. 
Several tools have been retired in this release: the UNIX ST-Workbench tool, the EXPRESS to IDL compiler, and the outdated CD SDAI library.
The schemas for the IGES and DXF conversion tools have also changed slightly since the last release. In order to satisfy the more accurate checking of the new unified EXPRESS compiler, we had to change a few attribute names and so on. There have been no substantive structural changes.
In the IGES schema, the primitive types referenced by the datum select have been renamed to int_val, float_val, str_val, and bool_val to avoid a conflict. In the DXF schema, we changed the name of the Insert entity to insert_at and the name of the attrib.value attribute to attrib.attribValue to avoid conflicts with reserved words.