You need RB 7.0 or higher to use it safely in a multi-threaded environment. We had to make RB threadsafe in order to support the new Report Server Edition 7.0. The report engine, RAP and DADE are not threadsafe in RB 6.03. Furthermore, BackgroundPrinting is a feature in RB 7.02.
If you are using RAP and DADE in a template, then this is easy to do in RB 7.02. Load the template to a report on a form, set Report.BackgroundPrintSettings.Enabled and Active to True and then call print and your report prints in the background:) You can even configure the application main thread report so that you show the print dialog and autosearch dialog in the main thread (because you call Report.Print in the main thread), and the values are transferred behind the scenes to the report that will be created and generated in the background thread.
Essentially, how we decided to support background printing was to create an instance of the form container where the report was owned. We pull the form class out and create an instance of it in a thread. This allows the data access components and event handlers to be running in the background thread with the report. Then we can pull the report object out, assign the print device options and any autosearch values to the threaded report, and stream the template before calling print on the report object in the thread. This means that the event handlers and the data access components must be thread safe. Usually, this only requires adding a session component with AutoSessionName set to true.
Comments
We had to make RB threadsafe in order to support the new Report Server
Edition 7.0. The report engine, RAP and DADE are not threadsafe in RB 6.03.
Furthermore, BackgroundPrinting is a feature in RB 7.02.
If you are using RAP and DADE in a template, then this is easy to do in RB
7.02. Load the template to a report on a form, set
Report.BackgroundPrintSettings.Enabled and Active to True and then call
print and your report prints in the background:) You can even configure the
application main thread report so that you show the print dialog and
autosearch dialog in the main thread (because you call Report.Print in the
main thread), and the values are transferred behind the scenes to the report
that will be created and generated in the background thread.
Essentially, how we decided to support background printing was to create an
instance of the form container where the report was owned. We pull the form
class out and create an instance of it in a thread. This allows the data
access components and event handlers to be running in the background thread
with the report. Then we can pull the report object out, assign the print
device options and any autosearch values to the threaded report, and stream
the template before calling print on the report object in the thread. This
means that the event handlers and the data access components must be thread
safe. Usually, this only requires adding a session component with
AutoSessionName set to true.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com