Two-way communication between classes

In the past everything was simple. My app does email archiving with a lot of options. For most of them I had code like

dim thePrefValue as String = Globals.thePrefs.GetPrefString("Schedule_TimeFrame")

to get the value and

Globals.thePrefs.SetPrefString("Schedule_TimeFrame", GetScheduleValueEnglish(me.Text))

to set the values directly. Now I want to have multiple sets of options. There is going to be a class that holds the option sets. But how do I do the communication between this class and the individual controls. First I thought about the observer pattern, but the communication needs to be two-way. Also, the central data class and the individual controls aren’t really related to each other. Can/should I use notifications? Any other ideas?

one idea is to make class A a property of Class B
this way A and B can “talk” all they wish.

And other controls can (if required) have a “Class A” property that points to the same instance as another control

Better set an interface which can be called from anywhere. So the interface implementation inside the class needs to know internal details and the other code has not to care about it.
I use a similar approach for read and write preferences from different control types in a window. I just loop over the controls as check via “aControl isA myInterface”.

@Dave S : this isn’t possible. The options live in different containers so that there is no “Class B”.

@Thomas Eckert: your idea might be more interesting. How would the interface look like? Not sure if this is feasible as my window is 4 levels of containers deep.

I generally write separate classes that handle all the business logic for my windows, rather than fill the window with lots of code in the events and controls. I add instances of these business logic classes as properties on the App class. With this pattern, I can refer to controls from anywhere like this:

mainWindow.containerControlName.ControlName

And I can call methods to perform business logic from outside the window itself like this:

app.mainWindowBusiness.methodName(param1, param2)

Of course I do limit some things with scope, so that the business logic classes have only exposed certain methods globally.

This approach makes it very easy to do what you are looking for: When the controls need to update, they just ask their business logic class to tell them what their values should be. The business logic class can pull whatever it needs to from the class that holds your control sets, and give it all back to the window controls as needed.

@Kimball Larsen : yes, this is fine for business logic where you have a direct communication path.

I think I’ll go with the notifications.

Each control is part of the interface. There is a base interface and each control type has its own class which has also that interface and implements the specific methods for that control. So each control “knows” what type of preference needs to be saved. E.g. a checkbox has a boolean entry, a Text Field a string and so on.
In my main code I need just to loop over the controls and check via “isA” for the interface base class and call the functions.

@Thomas Eckert: thanks for the explanation. My window is too complicated for this.