next »

[Paul M.]

Is this now impossible when using the report writer?

Code

MAIN
 
  DEFINE i                        SMALLINT
  DEFINE grw_handler              om.SaxDocumentHandler   
  DEFINE grw_handler2             om.SaxDocumentHandler   
 
  LET grw_handler = fgl_report_createProcessLevelDataFile("FILE1")
  START REPORT report1 TO XML HANDLER grw_handler
 
  LET grw_handler2 = fgl_report_createProcessLevelDataFile("FILE2")
  START REPORT report2 TO XML HANDLER grw_handler2
 
  FOR I = 1 to 10
      OUTPUT TO REPORT report1(i)
      OUTPUT TO REPORT report2(i)
  END FOR
 
  FINISH REPORT report1
  FINISH REPORT report2
 
END MAIN                                 

Everything ends up in FILE2. This is a very simple example.
I am currently changing existing ascii reports to use the GRW and in some case I do have reports starting at the same time that I need to send to xml as the reports are in the same for/foreach loop and using the same data but have very different outputs.

Do I now have to start rewriting code any time I need more that one report active at the same time?   

[Alex G.]

Hi Paul,
>Is this now impossible when using the report writer?

It is not possible to have two 4GL reports producing XML at the same time.
Perhaps the two reports cannot be combined into one larger report shipping the combined data of both.
If that isn't an option then the reports would have to be run in sequence as shown below.
 

Code

LET grw_handler = fgl_report_createProcessLevelDataFile("FILE1")
 START REPORT report1 TO XML HANDLER grw_handler
 
 FOR I = 1 to 10
     OUTPUT TO REPORT report1(i)
 END FOR
 
 FINISH REPORT report1
 
 LET grw_handler2 = fgl_report_createProcessLevelDataFile("FILE2")
 START REPORT report2 TO XML HANDLER grw_handler2
 
 FOR I = 1 to 10
     OUTPUT TO REPORT report2(i)
 END FOR
 
 
 FINISH REPORT report2

>in some case I do have reports starting at the same time that I need to send to xml as the reports are in the same for/foreach loop and using the same data but have very different outputs.

For this case you would call fgl_report_createProcessLevelDataFile("FILE1") as you have done in your example and later when the file is complete you can call fgl_report_runReportFromProcessLevelDataFile(handler,"FILE1") any number of times with different outputs (e.g. PDF, SVG, ..) or even different designs.
Example:

Code

#First generate the process level data file called "FILE1"
LET grw_handler = fgl_report_createProcessLevelDataFile("FILE1")
 
START REPORT report1 TO XML HANDLER grw_handler
 
 FOR I = 1 to 10
     OUTPUT TO REPORT report1(i)
 END FOR
 
 FINISH REPORT report1
 
#Show the report using "invoice.4rp" for SVG viewing.
IF NOT fgl_report_loadCurrentSettings("invoice.4rp") THEN
    RETURN FALSE
END IF
LET grw_handler=fgl_report_commitCurrentSettings()
 
IF NOT fgl_report_runReportFromProcessLevelDataFile(grw_handler,"FILE1") THEN
    RETURN FALSE
END IF
 
#Create a PDF copy for archiving using the design "archiving_invoice.4rp".
IF NOT fgl_report_loadCurrentSettings("archiving_invoice.4rp") THEN
    RETURN FALSE
END IF
CALL fgl_report_selectDevice("PDF")
CALL fgl_report_configureOutputFileName("invoice"||invoiceNumber||".pdf")
LET grw_handler=fgl_report_commitCurrentSettings()
IF NOT fgl_report_runReportFromProcessLevelDataFile(grw_handler,"FILE1") THEN
    RETURN FALSE
END IF

There is also an alternative function "fgl_report_setProcessLevelDataFile(STRING fileName)" which creates the process level data file on the fly in addition to the regular output. This way you can for example have a report produce SVG output with can be viewed while the report is still running (In the previous example we had to wait for the report to complete creating the process level data file before we could view the first page) while producing the data file at the same time.
Example:

Code

#First show the rendering of the design "invoice.4rp" in the "SVG viewer and at the same time record a process level data file called "FILE1"
IF NOT fgl_report_loadCurrentSettings("invoice.4rp") THEN
    RETURN FALSE
END IF
CALL fgl_report_setProcessLevelDataFile("FILE1")
LET grw_handler=fgl_report_commitCurrentSettings()
 
START REPORT report1 TO XML HANDLER grw_handler
 
 FOR I = 1 to 10
     OUTPUT TO REPORT report1(i)
 END FOR
 
#Create a PDF copy for archiving using the design "archiving_invoice.4rp".
IF NOT fgl_report_loadCurrentSettings("archiving_invoice.4rp") THEN
    RETURN FALSE
END IF
CALL fgl_report_selectDevice("PDF")
CALL fgl_report_configureOutputFileName("invoice"||invoiceNumber||".pdf")
LET grw_handler=fgl_report_commitCurrentSettings()
IF NOT fgl_report_runReportFromProcessLevelDataFile(grw_handler,"FILE1") THEN
    RETURN FALSE
END IF

Regards,
Alex

[Paul M.]

Alex,

Thanks for your reply.
We produce the xml output and then let the user view/print it later at their convenience.

I was hoping that there was a simple workaround. If it were only two I would try and combine them but i have a lot more on my convert to-do list, so run in sequence it will have to be.

At least I know now.

Regards,

Paul Murray.

[Alex G.]

Hi Paul,
out of interest:
>We produce the xml output and then let the user view/print it later at their convenience.
Do you do that for all reports? Isn't latency an issue on larger reports using this approach?
Using the "fgl_report_setProcessLevelDataFile(STRING fileName)" function you could allow users to produce the first instance as a latency free document. When the document generation has completed then the process level data file is also ready for use.
This file could then be archived for later selection by users as you described so that the overall functionality would be similar.
Regards,
Alex

[Paul M.]

Alex,

Yes, every report we produce are direct to a file and we have a program to list up a users reports and they can either view,delete or print them.
We have being doing it this way for about 20 years and its really never been an issue. Most want to see the final totals or summaries that appear at the end of the reports.

Regards,

Paul Murray.