Scroll List: How to pass information to/from backend from inside custom container items.

[RReta.1]

Version: Touch GFX Designer 4.16.1

Project is attached.

My question is similar to:

https://community.st.com/s/question/0D50X0000AFpwBx/can-you-call-a-method-on-view-from-a-custom-container

I looked at the ContainerCallback example that Martin posted and I think I understand what he is trying to show.

In that solution though, the View register itself to a known custom container name (i.e. customContainer11)

Screen1View::Screen1View()
{
	customContainer11.setPtr(this);
}

If my custom container is an element inside a Scroll list, where is a good place

to call setPtr()? from inside ListUpdateItem()? or is there a better place?

essentially I am looking to have the onGroupLightLevelChange() in my example to notify the View -> Presenter -> Model of a value change.

Also, if the backend want to influence how many items are displayed in the scroll list (e.g. item 1,3,5,8 in sequence) is there a good example on how to do that?

I am able to use lightGroupListUpdateItem() in my example to dynamically generate the groupNames and set the slider value, but If i try to skip say group 3, by setting it notVisible/Touchable, The scroll list displays a gap between group2 and group4 and when I scroll the list, group3 becomes visible again.

Thanks for everyone's time.

[RReta.1]

Partially answering my own question on custom containers getting messages back via the correct View -> Presenter -> Model channels.

Following the example that Martin sets up for CustomCallback, here are the steps I end up doing (using my attached project as a reference):

• add a private/protected member to your custom container class (i.e. lightSliderGroup.hpp in my example) to store a pointer back to a presenter.
• create a public function in the custom container itself to let others set that pointer (e.g. void setPresenter(lightControlGroupPresenter* presenter);
• Then from inside your ListUpdateItem callback call item.setPresenter(presenter); - This makes every "visible custom container" that can accept gui event knows which presenter to use.
• Finally in the custom container's onGroupLightLevelChange() implementation you call presenter->SomeMethod(someArgs); for whatever you need to get the backend to respond.

Not quite sure on the finer points of passing a pointer to a view vs a presenter. I end up using presenter since it seems like a simpler approach than to call a method on the view only to have it call the presenter's method.