Hi Dojo,
Recently I noticed unexpected behavior: when performing sets from an automation script to a parameter that triggers an QAction with a Thread.SLeep in it, I observe that the automation script is delayed for the amount of sleep defined in the QAction even with the flag "NoCheckingSets".
So the following automation script takes 20s to execute. (Please find the automation script and the connector here)
FYI: I also tried removing the read parameter and putting it the logic on the write parameter (and trigger the QAction on the write) but the behavior remains the same.
Is this behavior expected? I was in the understanding that when the flag "NoCheckingSets" is on, the automation script would not be blocked just do the sets and the element would catch up... (DataMiner 10.4.11.0-15028)
This is the connector:
Hi Timothy,
What I can say for sure:
- The NoCheckingSets flag is not about making the call sync or async. It\'s \"only\" about: do we want to verify if the read parameter was properly updated to the value you sent in your set method call.
- no matter if you use a sync or async call, on the destination element side, the set will be added to the SetParameterThread and the QAction you trigger on it will indeed happen sequentially, one at the time, so that each QAction run can retrieve the appropriate value you sent from your automation script. Otherwise, you would likely end up processing multiple times value \"D\" instead of processing value \"A\" then \"B\", then \"C\" and eventually \"D\".
I wasn\'t sure if normal sets from script would be sync or async but based on Jorge\'s answer, they seem to be sync.
Also note that if you use https://www.nuget.org/packages/Skyline.DataMiner.Core.DataMinerSystem.Common nuget package, there you\'ll have access to 2 different SetValue method overload, one where you can configure a timeout time and expected changes and one where you don\'t. Those 2 calls will be async.