How do you pass or use parameters with the Explorer

rbuser

I am starting to build out a Server ISAPI application to dish up reports
that have already been built using a form based application.

I have been reading the Developer's Guide and it shows how to build the
ISAPI dll and deploy it to show the explorer for the user to traverse to
launch reports.

It makes no mention as to how we can provide input (date ranges) that the
underlying stored procedure that the report relies on needs?

How is this done?

Thanks,

--
Reid Roman
Future Generation Software
http://www.fgsoft.com

nardmoseley

One option is to use the AutoSearch parameters feature. See
RBuilder\Demos\AutoSearch. This feature is supported by RB Server. The
other option is to use the custom Session and Report parameters that were
added to RB 7.02.

Check out the custom parameter related demos in RBServer\Demos\. There is
one for the Server, the WebTier and the Client. Each project contains a
ReadMe.doc and commented code.

Note: If your are a registered user of RB 7 Server Edition and you do not
have RB 7.02, please contact info@digital-metaphors.com with your full
registration info, including serial number.)



--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com

rbuser

rbuser

You can do what you want to do using AutoSearch params. Configure the data
query to setup the params you want and then save to the webserver tier. Test
the form using the built in autosearch generated form to make sure it is
working as expected. If so, do a view source on the search form and you'll
see where the form posts to as well as all the fields used.

Using that info, build your own form to match the necessary parameters and
you should be alll set.

rbuser

rbuser

I'm working on a new and improved version using a similar approach but with
an interface that can be queried to obtain a list of folders and reports as
well as another interface that will (hopefully) provide the autosearch
fields and field types.

The intent is to set up both of these as SOAP objects so that you can easily
query the server for a list of available reports and also dynamically
generate your own search form based on a second SOAP request for the
autosearch field details.

This seems to be far more useful in 'real-world' applications where you
might have numerous end users publishing various reports to a central server
and need a quick and easy way to interface with those reports with as little
custom coding as possible. Re-usability is the key here.