Changing scene in Model.cpp fails

[starcin]

I have a hardware trigger that needs to change a scene (think a Home button but I cannot use a hardware key event).

I am trying to change the scene for days but I cannot find a working solution.

The best looking solution was this: https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/how-to-implement-quot-switchscreen-quot-in-touchgfx/m-p/384809

Using this method crashes the code. Well technically the code is stuck in this loop in syscalls.c:

void _exit (int status)
{
  _kill(status, -1);
  while (1) {}    /* Make sure we hang here */
}

My code in the model is like this:

void Model::tick()
{
	uint16_t buttonState = getButtonState(16);
    if (buttonState != previousButtonState)
    {
        if (modelListener != 0)
        {
            modelListener->onButtonStateChange(buttonState);
        }
        if (static_cast<ButtonEnum>(buttonState) == ButtonEnum::MENU)
        {
            static_cast<FrontendApplication*>(Application::getInstance())->gotoSplashScreenScreenNoTransition();
        }
        previousButtonState = buttonState;
    }
}

I also tried to increase the minimum heap size since I saw it may be the cause.

The gotoSplashScreenNoTransition() is automatically generated since it is may entrance point.

[Marc_LM]

@GaetanGodart, would it be worth it to have a callback to the MVPaplications for things like this?
Some global upkeep function that needs to be called per ticks(2) or per screen transition(1)?


(1) post ..\touchgfx\framework\include\mvp\MVPApplication.hpp::finalizeTransition() ?

(2) Sorry I don't know how to make a handleTickEvent, that doesn't overwrite the current view.

[GaetanGodart]

Hello @Marc_LM ,

Can you explain more in detail what you want that callback to the MP application to be like?

Also, your links are not clickable. :)

Regards,

[Marc_LM]

Let's take @starcin example.
He needs an update every screen transition.
So the setup would be that you register a 'void ModelScreenTransitionUpdate()' after the MX_TouchGFX_Init but before the osKernelStart.
Each time the finalizeTransition is done, it would follow up with ModelScreenTransitionUpdate().

That way, Starcin could write this routine only once and not have to remember to add the pointer nuller in every new setupScreen().

Previous post notes:

(1) That is a relative url to each project, I can't give you something clickable.

(2) For the tick based approach, my conclusion would be to add everything in the model.tick handler to comply with .