I’ve been tasked with creating an operator GUI for a product line that will be tested via OpenTAP, and I have a basic prototype working. However, for some reason the Dialog steps do not produce a dialog.
When I view the results log, I can see that the step is executed and immediately passes. If I execute the plan in PathWave, a dialog appears and waits for me.
At the moment, my GUI code is basically the example found here: opentap/sdk/Examples/TestPlanExecution/RunTestPlan.Api/Program.cs at main · opentap/opentap · GitHub
I had something more complex, but in efforts to debug it, I’ve reduced the run portion of the code to the bare minimum.
Hi @matthewdumas, and welcome to the forum!
You need to implement an IUserInputInterface.
For more complex GUI topics, you can look into the TUI. It is an open-source editor and executor UI that you can use as a reference: For UserInputs specifically, see: opentap-tui/OpenTAP.TUI/TuiUserInput.cs at main · StefanHolst/opentap-tui · GitHub
Hi @rolf_madsen, right after posting the project got back-burnered, and now I’m back on it for a little while.
I took the time to look into your advice today, but I may have explained poorly. I’m not trying to build a new dialog, rather, I’m wondering why the built-in dialog step doesn’t function when I run it via the demo operator gui code. I can’t seem to see a way to implement that interface such that the operator gui will display it. Is there an event generated by the API that I need to capture? The BasicSteps.DialogStep seems to hand everything off to UserInput.Request, but I’m not seeing where that should be handled in the operator gui code.
Thank you for your help, I had hoped to get back to you earlier.
I must admit, it is going to be a bit complicated to support this in a generic way if you are developing a custom UI. However, if you literally only want to support requests from the dialog step it might be a bit simpler.
First you need to implement the IUserInputInterface interface in some class.
Then when you application starts up, you have to register it using UserInput.SetInterface();.
Once you have done that you will start to get various events through the RequestUserInput method. You might get other events on top of the one from the dialog step, but you can filter it based on type information.
You can use the AnnotationCollection class for a generic way of displaying the information from the dataObject inside the callback, or you can roll your own using reflection.
As I mentioned before, there is a full example of this in the TUI application.
It sounds like the better option would be to just roll my own dialog plugin and incorporate that into the GUI.
Now that I have some idea of how the interfacing is achieved I think I should be able to find the representative code in TUI. Just to make sure I understand what I’m looking for, it sounds like what you’ve said is:
- Register the main GUI as an interface
- Capture the RequestUserInput associated events
- Filter events to just the dialog
- Style a new window/dialog using the AnnotationCollection
At the moment I’ll be looking through the TUI for how they implement this, and will mimic it.
Looks like this was almost the correct route. I have a basic popup now, there are some issues with it, but those will be easier than this.
The only difference between what I said above and what I have working is that I created a new instance of an IUserInputInterface, and used UserInput.SetInterface on that.