Hi
You can build a list of report names and their descriptions that have been saved in the database, and use this in a list for the user to select from. It is pretty good, very dynamic/responsive, but difficult to program and does affect how you describe reports.
Alternatively, and my pref, is to include a list of reports in a seperate table, with report name (as it exists in the database) and a meaningful description. I use this to form the list for the user to select (in this case your source for the combo), and reference a hidden value as the report name. To add new reports to the combo, I add them to the table and everything else looks after itself.
So:
- You have a list table with the report object name and a description;
- the combo has two cols, and is bound to the col with the report name (eg rptAudible) and displays a meanginful description;
- the bound col is hidden (ie width = "")
- your code reads:
DoCmd.OpenReport cmbSystemTyp, acViewPreview
With this model, a new report won't necessitate changing your code. Please note that your where string must be addressed spearately (if required).
Lastly & FYI, I use a ValueList table in all my databases, and wherever practical use it for listing values used in combos etc. The table structure is:
ListName: of this list - eg Title/Months
Value: for reference value: eg Mr/November
AltValue: an alternative display: eg Mister/Nov
Description: to defne meaning of this item
Index: to order the list by for this ListName
Therefore if I want to update a list or find what values I am using, I "always" know where to look. The obv exception to this rule is where a combo/list is referenceing database records, eg Invoice Numbers.
Hope this helps
Cheers
Steve