Always keep the adjustment Trigger property for the messages you receive. The goal is to notify the UI when all the properties are set after receiving the message, which, on binding, is triggered one by one when assigned and if changed.
One issue encountered is the if BP Cuff is disabled then teh measure button will also be disabled. So as prep one thing to do before running the tests is to verify the bp cuff is enabled or change the variable in teh system.conf
Is msg_id_dd_heaters_data really being published here? Should it be? ** This comment applies to all classes as it appears you've done this everywhere. Also, I think we typically list the timestamp last.
so the isActive is the internal property of ValueAdjuster and it is binded to the c++ property of <*>set. Similar to how we binded the value to the c++ property
I was thinking we could return BOOL to check if the request was successful, added it.
But as you clarified the dialin response will only confirm the delivery of message successfully, I can change all these signal functions to void Thanks!
Why the extra leading zeroes? If you want to ensure the literal is treated like a U32, you can do 0x00000001 or simply 1U, but I suspect the compiler will default to 32 bits anyway.
We can't have 2 alarms with ID 196. The enum only has the empty saline bag alarm. Looks like alarm 197 is duplicate of this 196 alarm you've added. I think you should just remove this new alarm 196 that you've added here.
Lets discuss and remove the NumPad from the ModalDialog that is the parent of many other dialogs which do not need NumPad. In this case it should be in the TreatmentAdjustmentVitals.qml
