Aborting a running testplan creates unhandled GUI error

When a “Run program” step is aborted while the program to execute is open you get first this window:
Abort

Pressing the Abort button twice (the first press does nothing) in this windows creates this log entry:
Abort2

But the executed program is still open and TAP ist still running and seconds are counting.

Now youo can press abort again twice to see the same picture. The log error will apper only once.
But the opened window never closes

If i then manually close the opened programm TAP shows the Aborted next to the step. This should have come immediately when pressing Abort i think.
Abort3

This is due to the interaction with the program. A cancellation token exists, but if it isn’t handled by the external program the Test Plan does not know the current state. We want to avoid explicitly sending task kills as that could cause issues depending on the application.

The way Abort normally works is it waits for an “OfferBreak” event to occur so it can ensure the state of execution.

1 Like

I opended the onboard Packagemanager.exe.
Perhaps handling the cancelation token can be integrated here easy.

I’m not sure what you mean by this. Can you explain a little more?

1 Like

In the Test Step Settings i selected the Packagemanage which is part if OpenTAP:


Settings

My idea was that the SW team that integrated the Cancelation Token in OpenTAP could modfy the PackageManager more easy than it would be if it is another company.

Ya, likely they could, but the Package Manager isn’t really an Application that make sense to use there.

1 Like

i could create a testplan where user has to install the needed packages at start of testplan before an external sequence call is running that needs these packages.

All the objects are needed when the test step starts, so in some very specific cases you may be able to get this to work, but likely not in general. If you were sequencing test plans from a separate application/campaign manager, then you could do something like this, but I’d recommend using the REST API for that.

1 Like

Regarding the stop/abort button, I think it would be great to have a visual indication that the button has already been pressed. Maybe it could change color.

Same for the open resources button.

2 Likes

@david-wsd I think this is a good compromise/improvement. We won’t be able to force an Abort (or an instrument to connect faster). But we can provide a better visual indication that we are waiting. Currently this can ger buried in the log. I will submit an inside for both.

2 Likes