Validator for current and desired value
-
Hi all,
I want to implement a class which validates the desired and current value.
Simple example:
I have a control in my UI which allows to turn on a light of a connected asset. The signal of turning on the light is transmitted to the asset and the asset responses with the current state of the light. Now, I want to check in the backend whether the light is on (the asset has taken over the status change) or off. Is the light off (the asset did not react on the the signal change) so that the current and desired value are different after a time x, the control of the UI shall be resetted.Does anyone has a simple and robust solution for the validation in mind instead of using a timer for each control.
Thank you.
-
@beckseba said in Validator for current and desired value:
the asset responses with the current state of the light.
So save that information somewhere (usually a member variable of some class instance) for your later retrieval (if you don't want to query the state from the asset at a future time).
-
@JonB - The state is saved in an IPC object, that is not the case. The question is how to implement an efficient validation routine. A potential solution could be:
The control in the UI is set (uiLight = 1) -> a timer is started for x milliseconds -> signal of the timer is emitted after x milliseconds: if (uiLight != isLight) do uiLight=0.
isLight is the current light status of the asset.
But I do not want to start a dedicated timer for each control. Is there any other efficient option?
-
@beckseba said in Validator for current and desired value:
But I do not want to start a dedicated timer for each control. Is there any other efficient option?
Sorry I don't really understand your situation. But if your only question is "I do not want to start a dedicated timer for each control" then why not do whatever is needed with a single timer used against all controls instead of one for each? That's all I can offer.
-
@beckseba said in Validator for current and desired value:
a single timer does not cover it.
It does if you adjust the timeouts to allow for that. I do it myself to avoid multiple
QTimer
s for multiple objects rather that each one having its own timer. I don't know whether that is necessary with Qt'sQTimer
s, but personally I regard them as a limited resource.