I would like to create a test step where the available parameters are not known until runtime. This includes the names of the parameters, how many there are, their types, and the metadata which determines how they appear in the UI.
@mullr A custom IControlProvider can accomplish the goal of dynamically named step properties, albeit with certain limitations. The approach is more involved than using the default property architecture of opentap, and you lose some of the engine/Editor’s built-in accommodations for properties. But IControlProvider essentially allows you to place any WPF UI elements you want into the Step Settings panel (or other panels). The sky’s the limit on what you show to the user.
@mullr The SDK examples solution does contain a custom IControlProvider example called PictureControlProvider, but it’s a very primitive example.
@david-wsd Thanks, that makes sense. Is there any way to do it in a way that will also work with the TUI? I’d like to keep my solution as portable as possible, if that’s feasible. Is
IMembersAnnotation perhaps useful here in some way?
@mullr What does “TUI” mean? The IControlProvider approach works great with the Editor. I always use IMemberAnnotation within an IControlProvider, so that the IControlProvider can call GetValue and SetValue on the test step’s property.
It’s the text-based user interface: https://gitlab.com/OpenTAP/Plugins/keysight/opentap-tui/
Wow, mind blown!
I’d probably assume that custom IControlProviders can’t possibly work in a text-based environment, but I wouldn’t know, I just learned that the TUI exists.
Do you have a finite number of possible step properties, or are the possibilities truly endless? If you had, say, around a 100 possible properties, you could simply define all of them in the step, then use the EnabledIf attribute to show/hide only the relevant ones. Cumbersome, but effective, and most likely portable to the TUI. But if you need it truly dynamic with unrestricted naming etc, that wouldn’t do it.
It’s completely dynamic. It’s actually driven by a user-provided schema that plugs into an external tool we’re developing.
@mullr : In addition to EnabledIf that @david-wsd described (useful when all combinations of your data structures are known beforehand and you can programmatically hide or show the appropriate settings based on a trigger), you can also completely dynamically and programmatically create TestSteps on the fly from an existing TestStep and place those in a TestPlan. In this case, you can choose to add the properties and data types you need programmatically to a TestStep class without having to know all the concrete definitions beforehand.
Please see an example here : https://gitlab.com/OpenTAP/opentap/-/blob/master/sdk/Examples/PluginDevelopment/TestSteps/DynamicStep.cs You can extend this capability with CodeDOM or Roslyn code generation to create your TestStep classes and replace an existing TestStep.
You could use two string arrays. One with the name of the parameter and the other with the value. Then convert the parameter in the called function to the needed type.