Parameters and AutoSearchValues

rbuser

Hello,

I wanted to share my experience of using Parameters and
AutoSearchValues. It may be that I'm doing something wrong but the
process of using these seems a little inconsistent depending on the
type of sql being executed.

My application is set up so that users can define reports in the end
user reports system and then either run them from the designer/viewer
or optionally link them to screens within the application. When the
reports are run from screens within the application I use the
OnGetAutoSearchValues to set up the values from data present on the
screen. I have turned off the AutoSearchDialog as it is not needed and
should not be shown.

This works fine for sql generated using ReportBuilder but is
impossible to achieve using ManualSQL. When the sql is ManualSQL it is
necessary to create a parameter to initialize the query. Unfortunatly
this is where it starts to get a bit inconsistent. If
Parameter.AutoSearchSettings.Enabled is set then users see the
AutoSearchDialog even though it is supposed to be switched off (Surely
this is a bug?). In addition, although the OnGetAutoSearchValues event
will fire after the dialog has been closed, any value assigned in the
event is ignored.

The answer to this seems to be to not set
Parameter.AutoSearchSettings.Enabled. This creates another problem
though. OnGetAutoSearchValues now does not fire at all and the
parameter cannot be edited at all unless a user has access to the
designer. I can handle the OnInitializeParameters event but this still
does not help users that are running the report from within
reportbuilder without designing priviledges.

I am left wondering why there are two such different classes for
essentially the same job in Report builder. Wouldn't it be better to
merge the two into one class which does the job consistently everywhere?


Regards,
Will.

nicocizik

Hi Will,

Parameters and AutoSearch are two separate features. The
AutoSearchSettings property of the parameters is present to control the
AutoSearch dialog (which can be used to update/initialize parameters).
In this case, an autosearch field is bound to the parameter to achieve this.

I first recommend reading over the following article about how
parameters should be used with ReportBuilder.

http://www.digital-metaphors.com/rbWiki/End-User/Fundamentals/Report_Parameter_Fundamentals

When using parameters and ManualSQL, you need to use the
OnInitializeParameters event rather than the GetAutoSearchValues event
to initialize the values.

Parameters are a much more versatile way to filter datasets with
ReportBuilder and allow users to manipulate report values from outside
the report. AutoSearch is also still a very useful feature and we will
continue to support it for backward compatibility.

rbuser

Hi Nico,
Thanks for your reply. I had already read through the article you
pointed me to and have done so again to make sure I have not missed
anything. Unfortunatly I'm still in a position where it is impossible
to do everything I need. Here is an example scenario.

1.) A user needs to call a stored prcedure which takes a single
parameter. i.e

Select * from AStroredProc(:aParam);

2.) AutoSearch values cannot be used directly because the sql must be
manual sql to call this stored procedure.

3.) Parameters must be used but have the following 'catch 22' :
With autoSearch switched on, the parameter value can be set manually in
the preview section of report builder. So far so good.

When the user runs the report from within my application where the
autosearch box is set to never pop up. It does so anyway. Whats more
any value entered or supplied in the OnGetAutoSearchValues event
handler is ignored. Not so good.

To get around this I can handle OnInitializeParameters and switch off
the autosearch feature on the parameter. However this creates the
problem that users cannot set the parameter value on the preview
section of report builder. Not all users have access to the design tab
to change the value there so I'm stuck.


Although I understand that parameters and autosearchvalues are
different beasts under the hood. I'm not convinced of the need to have
such vastly different and inconsistent behaviour when it comes to the
end users experience of them. After all, both of them have the same
basic job of supplying values to sql parameters. Would it not be
possible to unify the two when presenting them to end users?

Do you have any suggestions for how I could get this working in the way
I need it to work? The only thing I can think of at the moment is to
save two copies of the report, one for running inside the preview
section and one for running within the application. Not ideal though.

Regards,
Will.

nicocizik

Hi Will,

If I understand your requirements correctly, using parameters, you would
like to suppress the initial showing of the AutoSearch dialog when the
report is first previewed, but still allow your users to alter the
parameter values from the preview by selecting the autosearch button in
the toolbar.

Also, you have this behavior working for the AutoSearch feature but are
unable to get it working with Report Parameters.

- Is the above correct? If so, how are you acheiving this with normal
AutoSearch fields? Looking at the code and in our testing, suppressing
the AutoSearch dialog, will effectively hide the autosearch button in
the preview.

- If possible, please send us an example or description of how you are
suppressing the autosearch dialog yet still allowing your customers to
enter autosearch values from the preview.