This describes an older ST-Developer release (2006). You can find the details for the latest release here

What's new in ST-Developer v11

ST-Developer v11 includes a new Java API for STEP applications, out-of-the-box support for many STEP Application Protocols, the CIMsteel Integration Standard (CIS/2) and Industry Foundation Classes (IFC), more conformance checkers and many other refinements.

ST-Developer v11 Supported Platforms

Operating System Architecture Supported C++ Compilers
Hewlett Packard
HP-UX v11		 PA-RISC HP ANSI C++
MacOS X 10.4 (Tiger) PowerPC GCC 3.3 and GCC 4.0
(Xcode 2.0)
Linux
LSB 2.x or 3.x distros, RedHat 9, RHEL 3/4, SuSE 9.x, and others		 Intel x86 GCC 3.2, GCC 3.4, and GCC 4.0
Silicon Graphics
IRIX v6.x		 MIPS SGI C++ default and -n32
Sun Solaris v7 or better SPARC Sun C++ v4.2, Sun Forte 6, Sun Studio v7-11 (with and w/o -PIC -mt), GCC 3.4
Windows 2000/XP Intel x86 Visual C++ v6.0 and v7.0 (.NET) with /ST, /MT, and /MD options.

Supported Application Protocols

ST-Developer v11 ships with a wide selection of C++ and Java class libraries, HTML-documented schemas, and usage guides. You can start programming immediately, with out-of-the-box support for many STEP Application Protocols, plus the CIMsteel Integration Standard (CIS/2) and Industry Foundation Classes (IFC).

If we missed your favorite, you can use EXPRESS compiler and other ST-Developer tools to install them yourself! Look at the electronic manuals for quick links to all of the following. The latest release covers:

ST-Developer Library for Java

For fifteen years, ST-Developer has been the best C and C++ toolkit for processing STEP, EXPRESS and Part 21 data. We are now pleased to announce that we have added a new Java API for programming STEP applications.

This new Java binding alternative to the ROSE C++ library for those who prefer to program STEP applications in Java. It includes a new express2java compiler that generates classes from an EXPRESS schema.

EXPRESS to Java Compiler

The library is a pure Java implementation, and includes a set of base classes and interfaces declared in the com.steptools.stdev namespace. Among these are classes which provide data management and serve as the base for the classes generated by the EXPRESS compiler. Other classes hold EXPRESS data dictionary information and contain methods that implement a late-bound API to the STEP data. Plus, as we described above, ST-Developer ships with pre-built Java libraries for the common APs and other models like CIS/2 and IFC so can start programming immediately, just by adding the appropriate library to your classpath. 

    ap201lib.jar  com.steptools.schemas.explicit_draughting
    ap202lib.jar  com.steptools.schemas.associative_draughting
    ap203lib.jar  com.steptools.schemas.config_control_design
    ap209lib.jar  com.steptools.schemas.structural_analysis_design
    ap214lib.jar  com.steptools.schemas.automotive_design
    ap215lib.jar  com.steptools.schemas.ship_arrangement_schema
    ap216lib.jar  com.steptools.schemas.ship_moulded_form_schema
    ap218lib.jar  com.steptools.schemas.ship_structures_schema
    ap224lib.jar  com.steptools.schemas.feature_based_process_planning
    ap225lib.jar  com.steptools.schemas.building_design_schema
    ap227lib.jar  com.steptools.schemas.plant_spatial_configuration
    ap232lib.jar  com.steptools.schemas.technical_data_packaging
    ap238lib.jar  com.steptools.schemas.integrated_cnc_schema
    cislib.jar    com.steptools.schemas.structural_frame_schema
    ifclib.jar    com.steptools.schemas.ifc2x2_final

Refer to the ST-Developer Library for Java Reference Manual and associated javadoc descriptions for a complete picture of this new programming binding. The ST-Developer online documentation has the complete list of APs available as well as class listings, browsable EXPRESS definitions, recommended practices and more.

AP-209 Conformance Checker

We have added the AP209-specific conformance checking tool to our existing stable of AP203 and AP214-specific checkers, and the general AP checker.

The ap203check, ap209check and ap214check tools rapidly check data files against the local rules (WHERE clauses) and global rules (RULEs) defined in the AP-203, AP-209 and AP-214 EXPRESS schemas. The tool also checks for the presence of all required (non-OPTIONAL) attribute values in the data file.

AP209 Checker

The ap203check, ap209check and ap214check tools are faster than the more general apconform checker, but are specific to a particular schema. Whereas the apconform tool utilizes a general EXPRESS interpreter, ap2XXcheck tools use custom C++ optimized for speed and can check recommended practices and other things that do not appear in the EXPRESS schema.

Improved EXPRESS Compiler

STEP application protocols define entites with common names (point, line, address, vertex). If you are writing an application that uses geometry kernels, database engines, or other packages, you may end up with name clashes because some other package contains a "point" or "line" class. (For example, ACIS has conflicts with bounded_curve, curve, ellipse, pcurve, plane, surface, and vector).

In previous versions, you could specify the -name option in a workingset file to rename individual classes, but you could not easily rename them all. In this release, you can now specify a prefix to be prepended to all generated type names (entities, selects, and enumerations). You can give the prefix either on the command line or in a workingset file. On the command line, just call the EXPRESS compiler with the -prefix option. In a workingset file, add -prefix to the SCHEMA entry. The following examples will prepend "stp_" to all definitions in the AP-203 schema. 

    On the command line:
    > expfront -classes -prefix stp_ ap203.exp
     
    In a workingset file:
    SCHEMA config_control_design -prefix stp_

Instead of C++ classes like product and cartesian_point, you will get classes named stp_product and stp_cartesian_point. In the workingset file, if both schema prefix and -name are given to a particular type, the -name will be used for that type and the prefix will be ignored.

We have used this feature to add the "stp_" prefix to all of the pre-installed class libraries for the STEP application protocols.

Part 21 File Enhancements

The ROSE library reads and writes STEP Part 21 files. This release adds several key enhancements to make reading and writing much more flexible, particularly to files with non STEP extensions (like .IFC), files with comments in them, and files that need more control over the schema name in the header section.

In addition, we added the RoseP21Parser.h and RoseP21Writer.h headers to rose.h so it is no longer necessary to #include them separately when accessing some of the advanced Part21 settings.

Read and Write Files with ANY Extension

The ST-Developer libraries now read and write STEP files with any extension, files with periods in the name, and Windows directory paths with forward slashes, backslahes, and drive specifications.

The RoseDesign class now has a path() function for getting and setting the full pathname of a file in one call. The name(), fileDirectory(), and fileExtension() functions are still available. 

    RoseDesign * design;
    design-> path ("/foo/bar.baz");
    print ("design will be saved as %s\n", design-> path());

We also made the findDesign(), newDesign(), and saveAs() functions handle filenames in a simple, consistent fashion. You can pass a simple name or full path to any of them. If the name has no extension, we will add ".stp", but if you provide one, we will use it.

Creating a design and then doing d->save() gives: 

    d = new RoseDesign ("foo");              => ./foo.stp
    d = new RoseDesign ("foo.bar");          => ./foo.bar
    d = new RoseDesign ("/baz/foo");         => /baz/foo.stp
    d = new RoseDesign ("/baz/foo.bar");     => /baz/foo.bar
    d = new RoseDesign ("/baz/foo.bar.stp"); => /baz/foo.bar.stp

You can also call saveAs() at any point to save the file with a specific name: 

    d-> saveAs ("foo");                      => ./foo.stp
    d-> saveAs ("foo.bar");                  => ./foo.bar
    d-> saveAs ("/baz/foo");                 => /baz/foo.stp
    d-> saveAs ("/baz/foo.bar");             => /baz/foo.bar
    d-> saveAs ("/baz/foo.bar.stp");         => /baz/foo.bar.stp

Searching for designs finds the following. Searching for names without an extension will still match all of the common Part21 extensions. 

    d = ROSE.findDesign ("foo");              <= ./foo.{stp,step,p21,etc}
    d = ROSE.findDesign ("foo.bar");          <= ./foo.bar
    d = ROSE.findDesign ("/baz/foo");         <= /baz/foo.{stp,step,p21,etc}
    d = ROSE.findDesign ("/baz/foo.bar");     <= /baz/foo.bar
    d = ROSE.findDesign ("/baz/foo.bar.stp"); <= /baz/foo.bar.stp

Preserving Comments

Application can now read and write comments on the entity instances in a Part 21 file. Comments on individual entity instances may not be too useful for production files, but can be very helpful in sample datasets for training or documentation, particularly when combined with the other options for controlling the numbering and ordering of instances in the file.

The RoseObject::entity_comment() function gets and sets the comment which appears before an entity instance in a STEP physical file. Given the following: 

    calendar_date * cd;
    local_time * lt;
    cd-> entity_comment ("This is my date instance");
    lt-> entity_comment (" This is\n...my time instance\n ");

A STEP Part 21 file will have comments as follows. Note the use of embedded newlines in the second example to spread the comment across multiple lines: 

    /*This is my date instance*/
    #58=CALENDAR_DATE(1993,17,7);
     
    /* This is
    ...my time instance
     */
    #59=LOCAL_TIME(13,47,28.0,#29);

When writing, the comment will always appear on the line before the entity instance, separated by a blank line from the previous instance.

When reading, comments are normally discarded and entity_comment() will just return null, but you can force the file processor to save them by adding the following lines to your application program: 

    /* somewhere in your main, before you start reading files */
    RoseP21Lex::comment_fn = rose_p21_read_and_preserve_comment;

After you do this, the entity_comment() function will return a string containing all comments seen between the end of the previous entity and the end of this entity are concatenated together as one string.

Do not use this facility to pass "out of band" data in a Part21 file. Most tools strip or ignore comments. Also, this facility only preserves comments in the data section of the file. Header section comments are not captured.

Customized Schema Functions

Within the Part 21 file writer, the signatures for the custom read and write schema name functions have changed. Previously, the The read function took a char*. This has been changed to const char *. 

    typedef RoseErrorCode (*RoseP21AddSchemaFn) (
        RoseDesign * design, 
        const char * name   /* now a const */
        );

The change to the write function is slightly larger. Previously, it took one argument, a pointer to the schema. Now it takes two. The first argument is a pointer to the design object being written, while the schema pointer has moved to the second argument. The write function now more closely matches the arrangement of arguments to the read function, plus the design pointer allows the function to examine the contents of the design as part of its processing. 

    typedef char * (*RoseP21SchemaNameFn) (
        RoseDesign * design,  /* added in v11 */
        RoseDesign * schema
        );
     

See the section on Customized Schema Handling in the ROSE Library Reference Manual for more information.

ROSE Library Enhancements

We have added a number of improvements to ROSE to simplify STEP data processing and improve the performance of applications. Consult the ROSE Library Reference Manual for a complete description of these capabilities.

Faster Usedin() with Backpointers

The RoseObject::usedin() function now uses backpointers to improve performace if they are present (from rose_compute_backptrs()). This can result in a significant performance boost if usedin() is called many times. Take care if you are changing the design at the same time, however, because usedin() has no way to know if the backpointers are out-of-date.

Simple Nested Select Types

We have added several functions that simplify dealing with the nested Select types that are common in the STEP Application Protocols.

The rose_get_nested_object() function searches possibly nested select objects until it finds an underlying entity instance. This function is a useful shortcut eliminates many "if-then" tests. You can also restrict the return value to a particular type. 

RoseObject * rose_get_nested_object(
	RoseUnion * sel,
	RoseDomain * filter = NULL
	);

On the other side, rose_put_nested_object() sets that value of a select to a given object and will create nested select objects as required to represent the value. If the top-level select instance does not yet exist, the rose_create_select() function can create and set it in one step. 

RoseBoolean rose_put_nested_object(
	RoseUnion * sel,
	RoseObject * obj
	);

RoseUnion * rose_create_select(
	RoseDomain * sel_type,
	RoseObject * obj
	);

See the ROSE Library Reference Manual for more information and some examples using these functions.

Reference Counting

Previous ST-Developer releases added the ability to compute backpointers for your entire data set. When an application only needs to know whether an object is referenced or not, the ROSE library can now compute reference counts for objects in a more space efficient way than computing backpointer lists.

The procedure is similar to the backpointer functions. An application computes the reference counts for a design, then processes the objects using the counts, then finally releases the counts and cleans up the space.

Use rose_compute_refcount() to initializes the counts, rose_release_refcount() to clean up afterwards, and rose_refcount() in the middle to test a particular object. The example below looks for any unreferenced objects in a design. 

    RoseDesign * design;
    RoseObject * obj;
    RoseCusrsor objs;
    rose_compute_refcount(design);
    objs.traverse(design);
    while (obj=objs.next()) {
        if (!rose_refcount(obj)) printf ("Unreferenced obj!\n");
    }
    rose_release_refcount(design);

If you modify objects, the counts are not automatically updated. However, you can use rose_refcount_inc(), rose_refcount_dec(), and rose_refcount_put() to maintain the reference counts when adding or deleting objects.

If you are deleting an object, you can decrement the reference counts of the objects referred to by its attributes using the rose_refcount_dec_atts() function. This only goes one level deep, but the rose_refcount_recursive_dec_atts() function continues to recursively decrement attributes of a sub-object if it becomes unreferenced.

Using this function, you could write a function to cleanly delete a tree of objects as shown below: 

    ListOfRoseObject objs;
    unsigned i, sz;
     
    rose_refcount_recursive_dec_atts(obj, &objs);
    for (i=0, sz=objs.size(); i<sz; i++) {
        rose_move_to_trash (objs[i]);
    }
    rose_move_to_trash (obj);
Copyright © 1991-2024 STEP Tools Inc. All Rights Reserved.