Override resetAction in ModuleWidget

Development
1

Is there a way inside ModuleWidget to tell if the reset happens? resetAction() isn’t virtual so I don’t think I can override it. I’m not seeing an obvious way, so I think I have to have the Module’s onReset ask the scene for its widget and call a method, but that feels really hacky to me. Is there something I’m not seeing?

2

You could set a boolean variable called something like doReset inside the module’s onReset() then in the module widget you could do this:

if (module) {
    if(module->doReset) {
        do your stuff here

        module->doReset = false;
   }
}

You might need to be a bit careful here though as I think the ModuleWidget is stepped at the screen frame rate so whatever reset action you do here would not occur in sync with the reset in the Module.

3

Yeah my current work around is this. Which is working so far.

void onReset(const ResetEvent& e) override {
	Module::onReset(e);
	if(APP->scene != NULL){
		ModuleWidget * moduleWidget = APP->scene->rack->getModule(this->id);
		dynamic_cast<ResetAwareModuleWidget*>(moduleWidget)->reset();
	}
}

It just seems silly for the rest event to go from Widget → Module → Widget. It seems like the Widget API should have a way to do extra logic when it resets.

4

I think the ModuleWidget is really intended to contain the panel components and handle UI side of things. ModuleWidget resetAction calls the reset methods of each ParamWidget which handles the re-initialisation of the knobs and switches etc. so I guess there’s meant to be no need for an override or a hook to do other stuff therein. You could always ask Andrew to create an onReset handler for ModuleWidget in the API if you need it.

5

ModuleWidget is the “view” of the data in Module. If you reset the data, the view is reset as a result, so there is usually no need for a reset event in ModuleWidget.

Perhaps you have an exceptional use case. What does your ModuleWidget need to do when reset?

6

Oh this module definitely falls in the “exceptional use case” category, so it totally is fine if it it isn’t easy to do in the API.

The module effectively is a sequencer with a keyboard on the panel. In addition to the data for each step of the sequence, the UI also has state for which note is selected with regard to the keyboard on the panel. Effectively the keyboard lights up to show the note of the current selected note. Since this data isn’t needed for the module to function I currently have that data living in the Widget.

7

I would move that data to your Module. Widgets should usually be stateless and read/write the state in Module.

8

If you don’t mind me asking, why? The data is only relevant while the module is being viewed and is not intended to be persisted. Its like “does the user have the module browser window open.” I’m not trying to question the statement, just understand the reasoning at a deeper level.

9

It could be this (apologies if you already know about MVC):

10

Thanks Mark! No apologies needed. I am vaugely familiar with MVC. I get the general concept but I’ve not worked at length with such a system.

My understanding though is even in MVC, the view might still retain some data that is very closely related to presentation and not closely related to the model. It is statements like the following that make me think that:

The controller also sends commands to its associated view to change the view’s presentation (For example scrolling a particular document). Source: MVC Framework Tutorial for Beginners: What is, Architecture & Example

That said. I totally understand there is not going to be just one right way to do things. And im sure there are plenty of different, successfully MVC implementations out there.

1 Like