Limiting the HDSimulator to static functions prevents you from maintaining any state between successive calls and is incompatible with the DenaliCanMessenger. It is an improvement to hold state information and allows us to use the DenaliCanMessenger. Using the DenaliCanMessenger and dialin eliminates the need to maintain duplicated codebases and allows for bidirectional messaging. Your squish folder was doing the same thing as dialin but on a smaller scale.
1 - The test scripts are run in a consecutive manner, not in parallel. Each test should be self contained. 2 - (See statement above). This comment is about dialin, not testsuites. 3 - (See statement above). This comment is about dialin, not testsuites.
I am not sure killing the QObject timer would be a good idea, but also I couldn't find any recommendation not to do it. Since any object has only one timer I have a feeling that by killing the object's only timer, then any refreshing or chores for any kind of signal/slot maintenance will be stoped.
I prefer to have a boolean flag to return from the virtual method in case we don't need it to handle the functionality we put there.
In verify state, we change the target pressure with the average pressure over the verify period. That pressure value is in float. For RO pump publish data, the data type for target pressure is float as well.
If the name needs to change, regarding our coding standard and also to medical industry standards, it should be: "TxStates" with 'x', not capital. TX has other meanings in other areas.
It is wrong to create an instance of HDSimulator each time you want to use any function in that class. 1 - this class has not been defined as a static class, therefore, all the listers in class will be listening for each instance and the question is which one is going to respond, or all will respond, and then we will have multiple responses. 2 -This class not only should have the "cmd_" functions as static 3 - But also it needs to be a singleton class if want to have listers.
The design and usage of the class are not correct.
Why the doGetDevices is a public slots, therefore, is publicly accessible while you have a property defined for that? That's one of the reasons why I insisted to use macros to avoid this kind of inconsistencies. Also, the name of the property/signal/slot does not match. if the property type is vTYPE and its name is vVARIABLE and the vSIGNAL is "Changed" then by PROPERTY macro definition it has to be like below with slot defined as private.
At the time, this must have been the latest commit on the dialin master branch. It isn't maintained manually. It's generated automatically when issuing the pip freeze > requirements.txt command.
Since any object has only one timer I have a feeling that by killing the object's only timer, then any refreshing or chores for any kind of signal/slot maintenance will be stoped.
That's the intention - to stop the timer. Since the UI is continually trying to reconnect to the last paired device while it is off, if a user goes into the bluetooth settings page and hits "Scan for devices", the timer is stopped during the scan to avoid conflicts between the timer and the scan.
I prefer to have a boolean flag to return from the virtual method in case we don't need it to handle the functionality we put there.
I changed it from tx to TX to make it clearer it was a constant, but to maximize readability I think it should be TREATMENT_STATES, or TX_STATES to align with our coding standard, not TxStates.
From our coding standard:
Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL
1 - I mean that timer is not only for handling our implementation it may have another purpose which we are stopping by killing the only timer it has. 2 - in your
