A dynamic procedure for a report is regenerated whenever a report is printed or compiled from the main Reporter window. These dynamic procedures can now be re-executed (avoiding the retranslation which occurs with Print) during the current session or saved to export files. Exported report procedures may be imported to any OpenROAD 4.1 application (which must include repcomp.img and repopen.img). Some modifications to the dynamic procedures were made to remove assumptions that they are being run within the Reporter environment.

Each report procedure has an associated print dialog frame, which is typically seen when a report is run within Reporter. This frame optionally may be exported with the procedure. This frame provides default parameters for the procedure and allows users to set the target database, database flags, temporary directory, and the name of the intermediate file. This frame is not required to run the report and the developer may call the procedure via callproc, just like any other 4GL procedure. The call interface to a report is defined later in this chapter.

A major part of these changes is related to reports that use Image Trim as part of their output. Note that Image Trim is a static part of the report definition used to enhance the look of the report and is not user bitmap data retrieved through Image Fields from the user's data tables. 4GL procedures cannot contain initialized image trim objects, so the image trim used by a report procedure must be stored elsewhere.

During report definition these images are stored in the database or on disk. This makes porting of dynamic procedures difficult since the location of the required images is encoded within the report. If the images were originally stored in the database, the Reporter catalogs would need to exist and the images would need to be stored with the same unique keys and names. The only way this could be accomplished safely is to load the Reporter catalogs from the original design database.

For images stored on disk the same path to the image files would have to exist on the target machine. This requires bitmap image files to be deployed in addition to the report.

These mechanisms are still available but, in addition, more portable mechanisms are now provided for handling both types of image storage.

Database-resident images may be copied into an Image Server Frame, which is imported into the target application or an included application of the target application.

Before a report is run, an Image Server variable must be initialized with the Image Server Frame containing Image Trim required by the report. A global Image Server Variable (G_ImgSvr) of type u_imgsvr is provided in repopen.img (which must be included in any application that runs report procedures). An application developer may declare additional image server variables but a report procedure always expects to find its images in G_ImgSvr. An Image Server Frame may contain images for any number of reports and mimics the original database-resident mechanism for image storage.

When running a static Reporter-generated procedure from an application, an Image Server is used by default for any image trim originally stored in the design database.

The Procedure Tool provides the means to construct and update an Image Server Frame.

Disk-resident images may be installed in a single directory, which is definable at runtime, or through the environment.

The directory containing report image trim bitmaps may be named by the environment variable II_REPIMAGE_DIR or the report parameter PM_IMGDIR.