Hi,
I have noticed that I am not able to set a displayed parameter when attempting from its parent node (From the parent's children table).
I can confirm however, that it can be set from their own node view:
Is this behaviour by design?
Hi Reza,
This seems weird to me. I would expect both to work fine.
Are you sure the problem is not due to the refresh mechanism that is used?
If the first set did work fine sending the command for example, but if the refresh doesn't happen right away, this could explain why the second time you change it you see it immediately.
I would suggest to add a line of logging to the QAction to check if the code get's triggered or not. And then also verify how the re-poll mechanism happens. Maybe the device needs some time to accept the new configuration and the re-poll is too fast. adding a delay could solve this problem. (next attribute on sessions)
Let me know if you need further assistance here.
Hi Reza, I have made a test protocol in order to try replicating your afore mentioned issue. I was unable to reproduce this on my end. All updates are processed directly.
When I open the information events, I can also see all sets being processed right away. Both when executed from the original table, but also in the tree control in the parent level, table level, child page level and even sets in deeper childs (both via tables or direct parameters in the tree control).
Can you verify if you spot these information events? And if you see indications of missing Primary Keys or anything like that?
Another thinking path:
I’m not sure how “busy” your element is and how many links with scripts or external objects it holds that would be executing sets etc.
In case there are many items on the SetParameterStackThread, this could also explain the delay even when we are talking about a “Setter=true” action.
You could try and view the pending calls info on your element by following following investigation procedure:
https://community.dataminer.services/documentation/how-to-retrieve-protocol-pending-calls/
Here you could see if your element is busy and what other timers/groups/QActions might be delaying your element.
Goodluck with the investigations! Looking forward for your feedback on this quest 😉
Example above, is using a standard setter (setter =”true” on the displayed write parameter) and not a qaction trigger.
I did however, try with a qaction trigger and the behaviour is the same. In cases where I set the field from the original table, or from the node view of its tree control view, the qaction is triggered and when tried from its parent view, it doesn’t.
Is it by any chance reproducible on your end?