Creating Parameters
When creating a report that uses parameters, you have many jobs to do. You have to determine how the parameter will prompt the user to enter a value, determine the types of values that can be entered, decide if there are default values, and use the parameter within the report. The remaining portion of this chapter walks you through all the steps of creating parameters and using them in your reports.
New to Crystal Reports XI is the ability for parameters to present the user a list of live data values to choose from. In previous versions of Crystal Reports the user could only choose from a static list of values that you created in advance. The values weren’t able to reflect recent changes to the database. Crystal Reports XI now gives you this powerful new feature that connects the value list to the data source. This is discussed in more detail later in the chapter.
Creating a new parameter is controlled via the Create New Parameter dialog box. This is accessible via the Field Explorer window. Right-click on the Parameter Fields node in the Field Explorer window and select New.
Figure 4-6. Create New Parameters dialog box.
This dialog box has a multitude of properties that can be set and it’s going to take some time to discuss them all. So let’s start at the top and work our way down.
The top of the dialog box lets you enter the parameter’s name and data type. The parameter name is how you identify the parameter within the report (e.g. how you would reference it in a formula). It should be something that makes sense to you as the report designer. Although it will be shown to the user, it won’t be in a prominent position and you shouldn’t worry about how it looks to the user. Look at Figure 4-5 and you’ll see that the name is shown in the top right corner of each parameter prompt. It isn’t very obvious and most users might not even notice it.
The problem a lot of people have when they first start creating reports is that they give parameters generic names that don’t specifically state their purpose. For example, if a parameter is used to filter purchases by date range, then you might give it the name PrintDates. This seems like a good idea at first, but when you come back to make changes to the report in six months you won’t have any recollection about which dates this parameter is referring to. Is it the date the product was ordered or the date it was sold or the date it was shipped? You can’t tell by looking at the parameter name. You have to edit the record selection to find out which field it is being compared to. A much better idea would be to call it something like PurchaseDateRange. If you have to edit the report at a later date, you’ll immediately know what the parameter refers to. You want to keep the parameter names short, but also meaningful.
