Add multiple string responses to Message Popup Step

[ChrisHawk]

We found a need to customize the NI version of this step to give more functionality.  Our edits updates to allow multiple response text boxes (up to 10), and we added an option to configure the response to be a list controls rather than simple strings. Just added a Boolean to switch to list box and then the user just gives comma separated list of options with the default item first as the initial response string.

This is a simple change to the step and allows far greater flexibility for the step type (also it was easy to make the step upgradeable from the exiting step version maintainign the functionality if one or no string responses being used).

These features are very useful for collecting all UUT information during PreUUT rather than having to throw up popup after popup or create a custom module with a popup in it.  Would be great if these features could be included in the standard NI step.

[foxx]

Good idea, where can i find the example to download?

[dug9000]

Let me make sure I understand what you are proposing. You want a combobox/listbox of choices and you want the result as an integer index into the list? So the user doesn't actually type a string correct?

[ChrisHawk]

The update actually is in two parts; one adds the option to have multiple inputs, the other allows any of the inputs to be a combobox list instead of a string input (so the user has to select the option they want rather than free text).

So from the above the result is :

[warren_scott]

I see two possible use-cases where I would want to use something like this:

1) if/when TS natively supports enumerated types, that I could require the user to select from valid values for an enumerated type.  This would be statically defined at edit-time (based on the allowed enumerations of the variable/type) and as I modified the enumerated type the dialog would automatically adapt to the enumerated values.  This could get a little interesting for programatically modifying types (enumerations) on-the-fly.

2) be able to dynamically create a list of elements (array of strings?) and have the user select from a list of allowed choices.  For this situation, I don't know what the items are at edit-time, and the list will be different each time (think "I detected 3 instruments on the network with these different IP addresses, select the right one")

2a) provide the user with a drop-down list of items, but allow them to type their own value in if what they want is not in the list (sometimes I would want them to be able to do this, sometimes not).

One complication to add to this is it would be nice if this had support through localization.  if I am responsible for creating the list myself (option 2, 2a), I can run the list through the localization engine and all is good.  If option 1, it would be nice if the enumerated values displayed to the user could be managed through the localization files -- this way the enumeration selection could be in a language appropriate to ths user.