2019-05-21 10:53 PM
Hi, I have a common custom container that is included in all my views.
I need to access a method from the model, usually, in a view, I do this from the presenter, how can I do this in the custom container in a general way without passing the view to the custom container?
Thanks,
Eyal
2022-01-18 06:38 AM
Sorry for bringing up this topic again, but @Martin KJELDSEN , you said that we can create a commonBaseView to add the container, I think I get that, but shouldn't we do the same for the Presenter ? Let's say you want to do a status bar that include time in all screen, and get the time refresh by the model. the model will call the notifyTimeChange, that will be catch by a presenter. so this time value, all screen will just refresh the clock widget, so if we do not want every screen and presenter to have the same code for that, can we have a common presenter that will catch the notifyTimeChange event, and call the common view to update the container ? am I right ?
So every screen that require the time in status bar, must have its view inherit from the common View and its presenter inherit from the common presenter ?
2022-01-19 01:44 AM
Don't be sorry!
Yes, you also need a base Presenter. I'm not sure where my example is, but it should show you what's required. But the changes are made to the generated files, which is why it would be nice with a script - But we're still doing this feature. It's on the fast track now.
/Martin
2022-01-19 01:48 AM
2022-09-07 09:52 AM
As I also have like 20 screens with common container with a button and don't want to spend all day on handling the beautiful indirection.
I just made a kind of singleton of my model. Now I can call getInstance() on it and do whatever I need.
Let's face it - it's a common scenario. Let's say I have a button with the same function on each screen. Let it be "Settings". Each settings click works the same. Each one needs my model for some reason. So - the long way is to create a custom trigger on my settings container (the one that has the common button, I won't edit all views just to move the icon a little bit), then handle the custom trigger in each view that uses it. Or... another long way is to inherit all views from a common base. Or... a direct shortcut to the model from anywhere. When an action of a button is called, the screen is initialized and the model is created and bound. So - will it work? I already tested it. It works.
It's way faster. I still have the normal data flow, so the container exchanges the data with the view, the view with the presenter, the presenter with the model (via ModelListener). But new flow is this - I make custom interaction in my container (when button clicked), I choose "Execute C++ code" then type something like this "Model::getInstance()->myModelAction()". Works as charm, if you have any questions I can share my workflow.
BTW, as I understand correctly - the Model entity is "a model of the GUI" - not the model of the data or entire application. So it is the class that stores the state of GUI logic, knows which screen is displayed and can (theoretically) handle requests from all screens any time. To be more specific - from the currently active screen only. The standard way is to use custom triggers all the way, defining the callbacks, setting the callbacks, passing the callbacks and so on... It may be OK if you have a simple app, but when it's a hog with dozens of screens and containers - it's quickly gets unmanageable, at least in reasonable time.
In my app (HMI) I have operations that consist of multiple steps (screens) but the sequence of the steps depends on the device state. There are lots of identically looking buttons (like "Continue") and... Here's where my hack comes in. All "Continue" buttons lead (via a shortcut) to the Model, the Model knows where we are, what we have, and then decides where to go from there.
Example: app language not set? We go to the language selection. We click OK. Where now? If the system time is set, we go to the profile selection, if not, we go to the time setting screen. All that logic is contained now in one switch statement.