Comment Search

The object being waited for will always exist.

Instead, the buttonText should be added to the object that is being waited for. e.g.

 
your_var = names.o_treatmentStart_heparinSection
your_var["buttonText"] =  "{} DELIVERY".format(vText) 
waitForObjectExists(your_var)

To address this problem, in my current Dialin Branch I've created a dict_update convenience function that allows you to add or update a dictionary's key and value. It will return a new dictionary object without modifying the original. The default python update call modifies the original and doesn't return a new object. So, using dict_update allows a simple one-liner for situations like these.

Once merged with my branch, you can use

ui.utils.dict_update

and this operation can be simplified to a one-liner:

waitForObjectExists(dict_update(names.o_treatmentStart_heparinSection, "buttonText", "{} DELIVERY".format(vText)))

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

By using the template function notify in lines 349,350,351 they are not required anymore.
This shows how good/correct implementation helps to have a clean code.

deleted

Done, see TextEntry.qml

Done

Application is spelled wrong
What is this for?

See response above

please use (const &) for all the slots down here.

where the acceptableInput comes from the TextEntry component doesn't have such a property?

Please move it after # CANBus section.

the coverage is done without these object names on the Alarm design branch please remove them.

RESOLVED in CODE WALKTHROUGH.

Update param info.

RESOLVED

After looking into this, VIEW_DEF does not support bidirectional messaging but it should be okay in this case since you are just reading data from FW.

Fixed.

I fixed the equation and renamed the variables.

shouldn't be _treatmentBegin(Button/StartButton/TouchRect/Rect).

Fixed.

Again, just look at primary load cell for functional determinations. Redundant is just for safety. However, we do want to tare both when it's time.

Be careful of using this.
When you push and pop in order it's fine but when pop to an item randomly it's not safe.
If the object is not currently in the stack you may get an error and I don't know what is going to happen to the Application !!!
preferably don't use this, it's a stack and has to be pushed and popped in order.

RESOLVED in CODE WALKTHROUGH.

It's an effort that can be done later when we transitioning all the APIs to use the CANMessageHandler.
All the currently defined API methods are using the same camelCase naming.
it needs also to change all the test suits we already have.
So I don't think that's what we need to address as part of this code review.

Fixed.