Searching the web I haven’t found a way to do this yet. What I want to accomplish is…
TestStep #1: Defines Global Variables as [Output]
public enum DV_TEST_LIGHT_LEVELS
{
[Display(“MANUAL”)]
MANUAL = 255,
[Display(“OFF”)]
OFF = 0,
[Display(“2E”)]
MID = 50,
[Display(“2D”)]
FULL = 100,
}
[Output]
[Display("DV Light Mode", Group: "TESTER", Order: 1.5)]
public DV_TEST_LIGHT_LEVELS myLight { get; set; }
TestStep X : Defines a local using an Input<> method
Defines a control that should be shown only if the Input<> is a specific value from an Enum
[Display("Controled By", Group: "Settings", Order: 2.5)]
[EnabledIf("Option", DiagColorOptions.RGBL, DiagColorOptions.SRGBL, DiagColorOptions.CRGBL, HideIfDisabled = true)]
public Input<DV_TEST_LIGHT_LEVELS> myLevel { get; set; }
[Output]
[EnabledIf("myLevel.Value", DV_TEST_LIGHT_LEVELS.MANUAL, HideIfDisabled = true)]
[Display("Level", Group: "Settings", Order: 2.55)]
public byte Level { get; set; }
— Results in: —
EnabledIf Could not find property ‘myLevel.Value’ on ‘OpenTap.Plugins.IndiePlugins.SetColorDiag’. EnabledIfAttribute can only refer to properties of the same class as the property it is decorating.
Any ideas how to access the “Value” in an EnabledIf?
Not sure but based on the openTap examples the “.value” is not needed?
2 Likes
Hi Craig,
There is no way to access properties of an object in an EnabledIf
selector; only properties of the same object can be accessed in this way. I also looked into the source code and verified that accessing the value of an Input is not implemented.
That said, it is not clear to me why this is needed. EnabledIf
is an Editor feature to control what UI elements are available during editing, and will not have any affect while a test plan is executing.
On the other hand, Input
is a runtime feature to control the flow of data through the test plan, and is not typically used while editing.
Can you explain what you are trying to do?
1 Like
To simplify a testplan I have defined “Global” variables as outputs in the first test step. This step is designed uniquely for each specific product. Some of the variables use ENUM’s such as to select an operating mode. In the case of a lighting module going through DV test this may be set to 50%. In a derivative test (e.g., LTOE, HTOE, PTCE), this static value is changed in all steps which need to send a color command by simply changing the value in the first step. When using static values defined by the OEM, there is no need to display a “level” parameter on the test steps. However when setting the mode to manual the field becomes meaningful and should be displayed. Since I’m deriving the value from another test step that is configured prior to running the plan, I had hoped to access the “value” while configuring the step. Looking at your comment, I believe you are stating the value of the “input” has no meaning when in the editor but merely identifies a path for the data to be routed during run-time. If this is the case then there will not be a solution to hiding this property in the editor when the testplan is configured in a state where it is not used.
Okay, thanks for the information. I see why you would want to do this. Although we don’t support accessing member properties, you can always add a derived property to your step:
[Display("Controled By", Group: "Settings", Order: 2.5)]
[EnabledIf("Option", DiagColorOptions.RGBL, DiagColorOptions.SRGBL, DiagColorOptions.CRGBL, HideIfDisabled = true)]
public Input<DV_TEST_LIGHT_LEVELS> myLevel { get; set; }
[Browsable(false)]
public bool IsManualMode => myLevel.Value == DV_TEST_LIGHT_LEVELS.MANUAL;
[Output]
[EnabledIf(nameof(IsManualMode ), HideIfDisabled = true)]
[Display("Level", Group: "Settings", Order: 2.55)]
public byte Level { get; set; }
When I say Input
is a runtime feature, I am talking about the semantics of Input in general. Typically, the input would be computed during test plan execution. In that case, the Input value would not necessarily be available during editing. But in your case if the input depends on what was selected in a dropdown, it should be reliable enough.
You could also consider making myLevel
an external parameter. Then you would control it from the test plan settings instead of a dummy test step at the top of the test plan, and it wouldn’t have to be an input.
Thank you, I never considered using a lamba function to solve this. There was one unforeseen issue in your suggestion and that is when creating the testplan the Input is not initially associated with the “globals” step and so the lamba expression fails. The final solution is shown below in case anyone else runs across this need…
[Display(“Controled By”, Group: “Settings”, Order: 2.5)]
[EnabledIf(“Option”, DiagColorOptions.RGBL, DiagColorOptions.SRGBL, DiagColorOptions.CRGBL, HideIfDisabled = true)]
public Input<DV_TEST_LIGHT_LEVELS> myLevel { get; set; }
[Browsable(false)]
public bool IsManualMode => (myLevel.Step == null)? true:(myLevel.Value == DV_TEST_LIGHT_LEVELS.MANUAL);
[Output]
[EnabledIf("IsManualMode", true, HideIfDisabled = true)]
[Display("Level", Group: "Settings", Order: 2.55)]
public byte Level { get; set; }
1 Like