RAP access to main report in thread RB7.02/D6/EndUser

rbuser

I have a small RAP function to fill a TStrings with the AutoSearch
details. It references the main report as follows:

myEndUserSolution.ppDesigner1.Report.GetAutoSearchDescriptionLines(ltsResult)

For background printing that won't work- right?

1) Can I access/discover the report that invoked me, or do I have to
force the user to pass in a reference to it?

2) Additionally (or instead of) is there an easy way to reference the
specific instantiation of TmyEndUserSolution as this may prove useful
in general.

Thanks,
Rick Matthews
Dartek Systems Inc.

rbuser

Hi Rick,

1) AFAIK, you have to pass a reference. If there is only one report shown per time then you could log the reference. But I don't know if there has been some changes in 7.02.
2) the report owner should be 'TmyEndUserSolution'.

HTH,
Chris Ueberall;

digitalmetaphors

Yes, Chris is right. Pass the report as a parameter on the pass through
function instead of referencing the form variable to get at the report.
Then it should work in a backgruond thread because a second report instance
will be runnning in a background thread, and by passing the report reference
in RAP, you'll be passing the correct background report reference to the
pass through function.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Thanks Chris and Jim,

I understand the need to get the correct report instance.

Other threaded environments provide simple access to the thread
instance of the module. For example with IntraWeb you would say (from
the ever popular FishFacts demo):

"TFFSession(WebApplication.Data).FFDatamodule " to get the datamodule
for your thread. Is there a similar method for RB or can it be
discovered by iterating through some of the RB session objects?

Thanks,

digitalmetaphors

No, we don't have that feature. You could create a RAP pass through
function to do this. Pass the report instance as described previously, and
then in the pass through you have the report instance that is running in the
background thread. This object has to have an owner (this is how we create
the container form by pulling the class type out of the owner property of
the report or raise an exception if it is nil). You could typecast the owner
as the form/datamodule, since you know it is the proper report instance and
the form was created (invisibly) in the background thread. Although, the
state of the form/datamodule is the same as if you created it in a new
application, where the outside world doesn't affect its values or objects
that it publishes or makes publicly available from its interface. What we
may have to do is add CustomParameters on the background print request that
you can set it to configure the report with extra info to support printing
a new instance of the report in a background thread. Right now were'
streaming across the report template, autosearch criteria and the print
options to the backgroudn report from the main thread's report which spawned
the background thread process. We'll look into this on the to-do list.


Cheers,

Jim Bennett
Digital Metaphors