Changes were made to the following features of Reporter:

The following two items were added to the main menu:

Example is a new option added to the Edit menu of the Query Editor. This option is active when a table is selected in the graphical table display. An example type may be one of three choices:

The "Create" button is labeled "Create Field" or "Create Param" depending upon the context. It may not be always be visible.

The "Cancel" button is now labeled "Close" to reflect the fact that actions initiated in this frame cannot be undone directly; variables are created and edited by calling the Variable Properties frame (Buttons N and Magnifying Glass). Variables are deleted (trash can) permanently after confirmation if they are not in use.

When the variable list frame is called as a result of the user choosing to create a variable field or table parameter, any changes made to variables are kept whether or not the user selects "Create..." or "Close". Selecting "Create..." associates the selected variable with a field or table parameter; selecting "Close" simply aborts the association but does not affect any changes made to variables.

Is Table Name is a new indicator in the Expression section of the Variable Properties frame. You set this indicator when the variable is a table name parameter. This field is view only. The Query Editor controls the use of a variable as a table name parameter.

When a variable is a parameter, the EntryField Prompt allows the variable name to be replaced by an explanatory phrase in the Print Dialog Frame.

When a variable is a table name parameter, its datatype is always varchar and IsParameter is always TRUE.

The dynamically created dialog frame associated with a report has an additional toggle, Popup Errors. The default is FALSE. This toggle controls whether errors, mainly SQL, are displayed in a popup window. All errors are logged in the trace window in either case.

Report parameters now have an optional prompt or explanation string. Instead of simply listing parameters by name it is possible to display a brief explanation of what information is required.

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.