Hey Dojo,
I'm working on a driver that allows the user to set the display key on two tables as well as other columns. The issue is that when the display key changes, there's a chance that it ends up cancelling any pending sets that the user made. I'm curious if there's a way to prevent this issue, like delaying the display key change until after the other sets, but I haven't been able to find anything.
Thank you for your help,
Bauti
Users are allowed to change the display keys on two tables, which launches a QAction that verifies that the new display key is valid before setting it. When a user tries to change multiple values in a row while also changing the display key, we find that sometimes all the sets succeed, and everything is updated and sometimes some of the changes other than the display key fail and retain their value. I'll attach some images of the issue to the original post.
Hi Bautista,
When you try to set multiple parameters at once in that manner, each set will be processed individually.
Which, depending on how those are being processed in the background, could lead to situations like the one you experienced.
Could you let us know how those sets are being performed?
Are all of those triggering a (the same or different) QAction, or do some of them involve setting device parameters?
The display key set triggers a QAction which then sets the display key while the other columns are just setter=true
Could you provide us with a bit more detail about how you are processing the display key sets?
Are you doing GetRow and SetRow, or SetParameterIndexByKey, or GetColumns and SetColumns?
My reasoning for asking is to try and understand if the sets are being done and just overridden by your QAction, or if there is a problem.
Currently the display key is set by SetParameterByIndex, but I've also tested with GetColumns and SetColumns and the issue persisted. We tested the QAction also with commenting out the SetParameterByIndex and the issue went away completely, it seems that the issue is a result of setting the display key.
From the information you provided, those calls seem highly unlikely to cause the problem I was thinking.
Apart from a potential software issue, the only thing I can think of that could cause such behavior is if there is something else running in the background.
Could you please confirm one last thing? Can you check if your connector has any other QAction(s) or perhaps some timer/trigger/action on the XML that also manipulates that table?
While there are other QActions that can affect the table that run in the background, I have tested the driver with them disabled to make sure and the issue persisted.
Could you clarify a bit more about the issue you're encountering?
Typically, it's the primary key that's required to perform sets in a table — not the display key.
It would help to understand how you're using the display key and in what scenario the pending sets are being canceled.
Looking forward to your input.
Best regards,