Changes to Reporter
Changes were made to the following features of Reporter:
• Main menu
• Query editor
• Variable list frame
• Variable properties frame
• Print dialog
• Reporter procedure tool
Main Menu
The following two items were added to the main menu:
Query Editor
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:
• Self: (Default) The table is an example of a runtime table of the same name. This may include a schema.
• Temporary: the table is an example of a global temporary table. Reporter will automatically refer to the table as session.<tablename>. These tables may be created at runtime by the caller in the same session that the report will be run or may be created as part of Report/Setup using the OpenROAD syntax for declare global temporary table.
To drop a temporary table explicitly, use drop 'session.<tablename>'.
• Parameter: When a table is specified as a parameter you will be prompted to create a variable through the Variable List frame. Variables that are associated with tables are always of type varchar and are report parameters.
Notes:
– A temporary table may be a parameter. In this case define the example type as Parameter and pass the table name as session.<tablename>.
– Parameter tables may not have a schema attached within the Query Editor. If required, pass the schema as part of the tablename.
– In the graphical display area of the Query Editor, tables that are examples of temporary tables are prefixed with (T), and parameter examples with (P).
– Quotes ('') are required around the table name for the drop statement.
– When the example type is parameter, this option is available to view or edit the associated parameter variable.
Variable List Frame
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.
Variable Properties Frame
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.
Print Dialog
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.
Reporter Procedure Tool
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.
Reports Using Image Trim
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
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.
Notes:
• When an Image Server is used it is assumed that all database-resident images are available from the Image Server.
• A report run from the Reporter File/Print menu item will maintain its previous behavior; it will not use the Image Server since, in this mode, the report and its images must already exist in the database.
The Procedure Tool provides the means to construct and update an Image Server Frame.
Disk-resident Images
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.
Notes:
• If an image directory is specified by either method, all "disk-resident" images are assumed to be located in the named directory.
• If PM_ImgDir is set it will override any setting of II_REPIMAGE_DIR.
• If PM_ImgDir and II_REPIMAGE_DIR are not set, the original paths will be used for disk-based images.
• To force use of original paths even when an environment variable is set, use:
PM_Dir = '<embed>'
• Reporter File/Print always uses the original paths.