Since a number of bugs related to prompt sets and EXEC VARAs have been fixed in recent service packs, I decided to go back to the original approach and see if it might work. To my delight, I found that the AE is now clever enough to figure out the necessary order of evaluation of prompt set defaults, even when these defaults use EXEC VARAs and depend on other prompt set values that also depend on EXEC VARAs.
This is the latest version of the prompt set. I opted to create a dedicated EXEC VARA for each prompt set default that needs to be looked up. Originally I did this because reusing the same EXEC VARA led to cross-talk between the processes performing the variable resolution. I suspect that bug has been fixed, but I stayed with this approach to simplify troubleshooting. All of these EXEC VARAs call the same SCRI, but with different parameters. This SCRI in turn collect and assemble the data from other VARAs using GET_VAR. These VARAs are a mix of static, SQL, and EXEC VARAs. In one case, one of the parameters of an EXEC VARA includes a {}-style reference to an SQL VARA. (It’s a bit complicated!)
The data sources for the fields are similar to the EXEC VARAs used to set the defaults. They simply provide complete lists rather than single items.
When the workflow is executed, the SCRI is executed multiple times to look up the initial default values for the prompt set elements. If the user has previously executed this workflow, these values are loaded from a user-specific static VARA object. Otherwise, they are loaded in a field-specific way. (E.g., for the Prefix field, if not saved user default is found, the first available prefix is selected as the initial default.)
I also added a little banner at the top, displaying a message indicating whether or not the default values were loaded from previously-saved user defaults. This too uses the trick of a {}-style reference to an EXEC VARA in the field default. In order to get this to work, I had to use a temporary static VARA to store the message to be displayed*. (This static VARA is written earlier in the process by the SCRI that loads saved user defaults, and if no saved defaults were found, a different message is stored, read, and displayed.)
The Reset check box simply clears most of the other fields.
The Save defaults controls immediately saves the currently-selected values to the user’s settings VARA, and displays the result of this operation in the combo box. This way the user can save the settings without actually submitting the workflow.
I’m glad I finally got this working. It is complicated, but it demonstrates several tricks for running tasks behind the scenes even before the prompt set has been displayed, and building relationships and dependencies between the values looked up by these tasks.
* Object variables do not work for this sort of thing, probably because the tasks executed to evaluate/resolve prompt set defaults do not inherit the environment of the parent task (the workflow, in this case). A static VARA though can be shared between such tasks.