ChannelState

[chimneywindow]

Hello,

I have some difficulties with the ChannelState.
I am trying to turn a channels with the ActivationState on/off form the consumer side.

On the side of the provider I have the following:
//Provider
class ChannelProviderState : public SDCProviderComponentStateHandler<ChannelState> { public: ChannelProviderState(std::string p_descriptorHandle) : SDCProviderComponentStateHandler(p_descriptorHandle) { } ChannelState createState() { ChannelState t_newState{CHANNEL_DESCRIPTOR_HANDLE}; t_newState.setActivationState(ComponentActivation::On); return t_newState; } ChannelState getInitialState() override { return createState(); } };

On the consumer side I can access the current state with:

auto updateChannel{t_consumer->getMdState().findState<ChannelState>(CHANNEL_DESCRIPTOR_HANDLE)}; // works ComponentActivation::On received
But setActivationState() makes no change.
updateChannel->setActivationState(ComponentActivation::Off);
What am I doing wrong?

[FBaumeister]

Hello chimneywindow,
calling setActivationState on updateChannel or any other member function on other classes of the MDIB namespace it only changes its internal state.
When you are done setting up your state, you transfer it in one action.
On the provider side this is done behind the scenes (after returning). On the consumer side this is done via commitState.
See ReferenceConsumer: lines 484 -496 and check out the docs (doxygen) for SDCConsumer::commitState.
Does this help?

[chimneywindow]

Hello FBaumeister,

I tried the commitState() but I got the message

error: no matching function for call to SDCLib::Data::SDC::SDCConsumer::commitState(SDCLib::Data::SDC::ChannelState&, SDCLib::Data::SDC::FutureInvocationState&)

I also tried to update the ChannelState on Provider side with

updateState()

and got there

undefined reference to `void SDCLib::Data::SDC::SDCProviderStateHandler::updateStateSDCLib::Data::SDC::ChannelState(SDCLib::Data::SDC::ChannelState const&)'

[FBaumeister]

Oh now I see.
I'm sorry. Its related to issue #10 .
Both are derived from AbstractDeviceComponentState and the current version does not handle this case.

Edit: I will have a look at that.

[chimneywindow]

Ah okay I see the relation between the two issues,
but thanks for your quick response!