Home RAP
New Blog Posts: Merging Reports - Part 1 and Part 2

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

edited April 2003 in RAP
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.

Comments

  • edited April 2003
    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;
  • edited April 2003
    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


  • edited April 2003
    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,

  • edited April 2003
    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


This discussion has been closed.