runtimewidget.py

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

created a sub-task for this as DoubleSlider doesn't have this validation/active feature. // TODO : Will be addressed in sub-task DEN-6686.

created a sub-task for this as DoubleSlider doesn't have this validation/active feature.
// TODO : Will be addressed in sub-task DEN-6686.

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

created a sub-task for this as DoubleSlider doesn't have this validation/active feature. // TODO : Will be addressed in sub-task DEN-6686.

created a sub-task for this as DoubleSlider doesn't have this validation/active feature.
// TODO : Will be addressed in sub-task DEN-6686.

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

will be addressed later RESOLVED

will be addressed later
RESOLVED

will be addressed later, RESOLVED

will be addressed later,
RESOLVED

RESOLVED

RESOLVED

RESOLVED

RESOLVED

RESOLVED

RESOLVED

RESOLVED

RESOLVED

RESOLVED

RESOLVED

It is noted. Since this is part of the Arterial/Venous pressure feature and not the preTx_Uf, will be taking care of it as part of the code clean-up and integration I need to do later. By the way, ...

It is noted.
Since this is part of the Arterial/Venous pressure feature and not the preTx_Uf, will be taking care of it as part of the code clean-up and integration I need to do later.
By the way, it's not my solution and not even my approved one.

See the reply above.

See the reply above.

if it is a constant/read-only value that will be used mostly in qml, then better to be defined in QML unless otherwise required.

if it is a constant/read-only value that will be used mostly in qml, then better to be defined in QML unless otherwise required.

Removed.

Removed.

Your solution requires a code change to be made and the entire denali application to have to be rebuilt every time a treatment parameter needs to be adjusted by systems. This will not serve the nee...

Your solution requires a code change to be made and the entire denali application to have to be rebuilt every time a treatment parameter needs to be adjusted by systems. This will not serve the needs of the system team. To fulfill their needs it was requested at the time to put the values in a file. You and I agreed at the time that the treatment parameter ranges should be read from a file. These two treatment parameter ranges are being read from QML which contradicts our agreed-upon decision to have them read from a file.

Actually, this feature (Arterial/Venous Pressure) was done before Pre-Treatment Create feature. At the moment Pre-Treatment Create has been implemented existence of these parameters has been ignore...

Actually, this feature (Arterial/Venous Pressure) was done before Pre-Treatment Create feature.
At the moment Pre-Treatment Create has been implemented existence of these parameters has been ignored and another approach has been followed.
In general, If a simple value can be defined in where it is being used the most (in this case qml) it's better to be defined there and not to call multiple setter, getter for getting a simple read only value.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.