Setting programmatic changing of screens blocks on `makeTransition`

[lentscode]

I have 4 screens in my application and I want to change screens from code. For instance, I have a dynamic list of item in a View and, depending on which element is currently selected, at the press of a button it should take to another screen.

I generated the methods to change screen by setting Interactions from Designer FX that I know for sure they will not be triggered. So a simple `application().gotoMyScreenNoTransition()` in the same View should work.

However, when writing the method inside the View to call from the Presenter, I see that the applications blocks on the function `makeTransition`. I don't even execute that methods that changes screens, simply writing the code to do that seems to block the whole process.

This is where I get blocked:

Remind that I don't even define the transitions by myself, so I should not edit the FrontendHeap, should I?

[lentscode]

Using the debugger, I have noticed that the `heap.screenStorage.element_size()` is 0, although it should not be like that, since I have defined my screens via Designer.

The strange thing is that the other Partitions inside the `heap`, `presenterStorage` and `transitionStorage`, have not this problem.

[lentscode]

By the way, you can find the code https://github.com/ApexCorse/steering-wheel

[ferro]

Hi @lentscode 

if screen not generated by GfxDesigner, perhaps you forgot to register your screen in

gui\include\gui\common\FrontendHeap.hpp

UserDefinedViewTypes

UserDefinedPresenterTypes

[lentscode]

@ferro  All my screens are generated through Designer FX, so the already appear on the FrontendHeapBase.hpp. That's not the problem.

[lentscode]

I finally solved my problem, simple skill issue and bad understading from me.

Since TouchGFX (as I have understood) allocates memory for Views, Presenters and Transitions at compile time, we cannot have things like dynamic length objects like arrays in those classes.

 

In particular, in one of my Presenters I had an array whose length was not specified at compile time, so I assume that the memory allocated for the Presenter in question was too little to let this array contain values. The fix was simply give a static length to this array, assuming you know the max length it can have.

class MyPresenter {
private:
 // ...
 char* items[]; // BAD
}

// ---------

class MyPresenter {
private:
 // ...
 char* items[16]; // GOOD
}