/*! * * Copyright (c) 2019-2020 Diality Inc. - All Rights Reserved. * \copyright * THIS CODE MAY NOT BE COPIED OR REPRODUCED IN ANY FORM, IN PART OR IN * WHOLE, WITHOUT THE EXPLICIT PERMISSION OF THE COPYRIGHT OWNER. * * \file VHDOperationModeData.cpp * \author (last) Behrouz NematiPour * \date (last) 19-Apr-2021 * \author (original) Behrouz NematiPour * \date (original) 19-Apr-2021 * */ #include "VHDOperationModeData.h" // Project #include "GuiController.h" VIEW_DEF(VHDOperationMode, HDOperationModeData) void VHDOperationMode::onActionReceive(const HDOperationModeData &vData) { opMode ( vData.mOpMode ); subMode( vData.mSubMode ); fault ( vData.mOpMode == GuiHDOpModes ::MODE_FAUL ); service ( vData.mOpMode == GuiHDOpModes ::MODE_SERV ); init ( vData.mOpMode == GuiHDOpModes ::MODE_INIT ); standby ( vData.mOpMode == GuiHDOpModes ::MODE_STAN ); validateParameters ( vData.mOpMode == GuiHDOpModes ::MODE_TPAR ); preTreatment ( vData.mOpMode == GuiHDOpModes ::MODE_PRET ); inTreatment ( vData.mOpMode == GuiHDOpModes ::MODE_TREA ); postTreatment ( vData.mOpMode == GuiHDOpModes ::MODE_POST ); invalidMode ( vData.mOpMode == GuiHDOpModes ::MODE_NLEG ); if ( _standby ) { standbyStart ( vData.mSubMode == GuiHDStandbyStates ::STANDBY_START_STATE ); standbyWaitTreatment ( vData.mSubMode == GuiHDStandbyStates ::STANDBY_WAIT_FOR_TREATMENT_STATE ); standbyWaitDisinfect ( vData.mSubMode == GuiHDStandbyStates ::STANDBY_WAIT_FOR_DISINFECT_STATE ); standbyDGFlush ( vData.mSubMode == GuiHDStandbyStates ::STANDBY_DG_FLUSH_IN_PROGRESS_STATE ); standbyDGDisinfectHeat ( vData.mSubMode == GuiHDStandbyStates ::STANDBY_DG_HEAT_DISINFECT_IN_PROGRESS_STATE ); standbyDGDisinfectChemical ( vData.mSubMode == GuiHDStandbyStates ::STANDBY_DG_CHEM_DISINFECT_IN_PROGRESS_STATE ); } // Go to home is kind of tricky and needs to be managed here in the backend. // It seems we need more states. // It can be handled in the QML but two things will happen that none of which are good. // Problem : The issue is for example FW may change the opMode state to TPAR <=> STAN but during that, subMode is not changing. // and when it comes back to the opMode STAN again only opMode is changing which is not enough, // because we still need to know when we are in STAN what subMode of STAN we need to be in // and because that does not change QML, since FW change opMode STAN <=> TPAR then UI is doing nothing. // The solutions on QML side are: // 1 - On each standby change STAN <=> TPAR which is not good because if in STAN we need to go to anything other than Start/waitTreatment. // Issue : But then the home screen would jump. // 2 - And we can also check that if subMode is Start/WaitTreatment go to home in QML. // 3 - Make the sub PROPERTY as TRIGGER and if standby is true trigger them. // Issue : None of the two later ideas are good either, because FW is sending the HDOpMode message each second(maybe on higher freq later) // and then QML is updating itself on a high frequency, which is absolutely incorrect on UI side, // Final Solution: # - The solution though is to have a special state in backend C++ that checks if opMode is standby and subMode is state/waitTreatment // and if these conditions changed since the last time then signal emits. // Brief : *** So actually we have a mixed condition property *** home ( _standby && ( _standbyStart || _standbyWaitTreatment ) ); } QString View::VHDOperationMode::text() { QString text = Gui::enumString(static_cast(opMode())); return text; }