1. Control over formatting of parameter fields is now supported via the new “Preferred Viewing Locale” feature in CR 2008. This is a menu in CR 2008 (View > Preferred Viewing Locale) that lets you set the formatting defaults for the report. Not only does it control default formatting of dates, times, and numbers on the report canvas, but it also controls the formatting of values in the parameter list of values, and the parameter page. See the images below for an example. Preferred Viewing Locale is a bit long to type, so I’ve abbreviated it as PVL.
|Prompt Page with PVL set to EN-US||Prompt Page with PVL set to FR-FR|
The dates are formatted according to the date standards in the specified locale.
Numeric, currency, and date time parameter formatting is also controlled by the PVL setting.
2. Control over default values.
3. Request for an ‘ALL’ value.
Both of requirements 2 and 3 are met with the new optional parameter feature of CR 2008. When a parameter is flagged as ‘optional’, the report can execute without that value being set. The trick here is that any formula that attempts to reference an optional parameters that doesn’t have a value set will return an error. So we’ve introduced the new HasValue() function which allows you to check and see if the parameter has a value.
This is really powerful, because now you can reference your parameters indirectly through another formula (or custom function) that checks if the parameter has a value or not. If it does, then the formula returns the parameter value. If it doesn’t, then it can return whatever default value you wish. So if you want the default to be the day before, or last Friday, then you can code that logic into your formula that uses HasValue to check if the parameter has a value set or not.
Optional parameters were also intended to solve the ‘All’ problem. Basically, you want a parameter to participate in a record selection formula only if it has a value. If it doesn’t, then you want that filter to be disabled. By using optional parameters and HasValue() in your record selection (and new saved data section) formulas, you can include conditions in your filter only if the parameters in those conditions have a value.
4. A prompt screen design interface.
CR 2008 doesn’t meet this requirement, and I think that a public API to our prompts would be a prerequisite to implementing a design interface. We’ll consider this requirement for our next major release.
There’s a few other items on the prompting to-do list including:
- Support for hierarchies of unknown depth. Imagine the OLAP member selector as the cascading prompt UI.
- Support for manually entering values to a dynamic prompt.
- Better API support for default values.
- Support for more flexible UI presentations.
On the whole, CR 2008 is the payoff release for the work we did in XI to centralize the prompting infrastructure. Prior to XI, each viewer (and the designer) had their own prompting UI so consistently executing enhancements across all our viewers was incredibly costly and hard to do.
In XI when we did dynamic cascading prompts, we created a central prompt engine that served all the viewers* and the report designer. This was a huge plumbing job and the payoff is we now have a central prompting engine so it makes delivering valuable enhancements much more efficient. Without the work we did in XI, the CR 2008 prompting enhancements would not have been possible.
*Except the Java Applet viewer
Thanks for the feedback,