1 of 1 people found this helpful
This sounds like an awkward goal if it's really meant to be open-ended reporting.
I suspect that one needs to build the reports, including appropriate layouts and scripts, but leave some of the options open to user selection, such as date range, etc.
I did this with a large system that had reports growing almost weekly, finding it difficult to provide reporting buttons. My solution to the reporting screen real estate issue was to create value lists of report names by department, and give each department a popup menu from which to pick the report they wanted to run. The field had an onModify script trigger which then ran the appropriate script for the chosen report, complete with any dialogs or utility screens for entering parameters such as date ranges.
Stephen, thanks for the response. It was exactly the type of response i was looking for. I am looking for ideas for a better interface to the reports. i.e. the user getting to the report with as few actions as possible. In your example selection from the dropdown and press the tab key.
I hope you may have some insight on this question. Is there any easy way to get prompts (report variables) into a global or local variable without creating more database fields? I started looking at custom dialog boxes and it can display up to 3 fields from a database table, but I can't link those to a variable directly. I'm very familiar with setting variables in script steps as I'm an old programmer (COBOL). I am just trying to avoid adding database fields that will only be used for temparary choices.
In my example, you don't need the tab key on the popup-menu of reports. Using the onObjectModify trigger launches the scrpt as soon as you choose an entry from the list. I have the value of the popup field set to "Choose Report..." by default, and reset it to that value at the end of the reporting script.
As for variables: In each of my FMP files, I have a table for globals which contains no data from the regular tables, just things I want to use in the system. Among the fields in that utility/global table are 3 text fields, 3 date fields, and 3 number fields. This covers everything I am likely to need for the Show Custom Dialog script interactions, and these can be used for collecting variables before or after the appropriate script step is triggered.
My script trigger field (with popup menu) is another global text field which makes it available for use anywhere in the system from that globals table.
This allows me to leave all of the reporting choice fields separate from any regular data table, but they remain accessible to use anywhere in the system, even in a multi-file system. (When using data separation model files, I put all of these globals in the interface file.)