MDI Forms being "aware" of what happens on each other

[BobRoyAce]

I am designing an application, using Visual Basic in VS 2005, with a
MDI interface. It is possible for the user to have anywhere from zero
to many MDI forms open at any given time. It is also possible that
changes to data made on one form could result in the need to update
other forms that are open. An example might be that a record is added
to a table on one form, and another form has a combo box that lists
records from this table and now needs to refresh that combo box's
list. What, IMO, complicates things is that the MDI forms could be
opened in any order.

Sooooo...let's say you have the following:
Form1 (Event1A, Event1B)
Form2 (Event2A, Event2B, Event2C)
Form3

Further suppose that:
Form3 cares about Event1A and Event2A
Form1 cares about Event2B and Event2C
Form2 cares about Event1B

Perhaps there could even be "system-level events" that could occur
that certain forms would care about.

How could I implement something like this? The solution needs to take
into account that forms could be opened in any order. For example, if
Form3 is opened first, how and when will it be able to "subscribe" to
Event1A and Event2A when the corresponding forms aren't even opened
yet? Alternatively, if Form1 is loaded first, how and when will Form2
and Form3 subscribe to Form1's events?

If you could provide code samples, and/or point me to books or
websites with instructions, that would be great. Any insights and
direction would be greatly appreciated.

 

[CMoya]

The simplest solution (very easy) would be to implement a Broadcast/Listen
object with a "Send" method and a "Broadcast" event that children would
subscribe to. Declare an instance of the object globally (in a VB module).

Module Module1
'this instantiates the object globally
Public g_notifier As New MyBroadcaster
End Module

And then have the child forms add a WithEvents reference to it

Private WithEvents m_notifier As MyBroadcaster = g_notifier

The notifier class itself could look something like this:

Public Class MyBroadcaster
Public Event Broadcast(sender as object, data as object)
Public Sub Send(sender as object, data as object)
RaiseEvent Broadcast(sender, data)
End Sub
End Class

Or something like that.

 

[rowe_newsgroups]

I am designing an application, using Visual Basic in VS 2005, with a
MDI interface. It is possible for the user to have anywhere from zero
to many MDI forms open at any given time. It is also possible that
changes to data made on one form could result in the need to update
other forms that are open. An example might be that a record is added
to a table on one form, and another form has a combo box that lists
records from this table and now needs to refresh that combo box's
list. What, IMO, complicates things is that the MDI forms could be
opened in any order.

Sooooo...let's say you have the following:
Form1 (Event1A, Event1B)
Form2 (Event2A, Event2B, Event2C)
Form3

Further suppose that:
Form3 cares about Event1A and Event2A
Form1 cares about Event2B and Event2C
Form2 cares about Event1B

Perhaps there could even be "system-level events" that could occur
that certain forms would care about.

How could I implement something like this? The solution needs to take
into account that forms could be opened in any order. For example, if
Form3 is opened first, how and when will it be able to "subscribe" to
Event1A and Event2A when the corresponding forms aren't even opened
yet? Alternatively, if Form1 is loaded first, how and when will Form2
and Form3 subscribe to Form1's events?

If you could provide code samples, and/or point me to books or
websites with instructions, that would be great. Any insights and
direction would be greatly appreciated.

In a similar project, I had the MDI parent subscribe to all the
necessary events that the child forms exposed. Then, when the event
listener fired on the MDI parent, it would fire a new event letting
the child forms know that they need to update. That way the child
forms don't need to worry about each other, they just need to listen
to the events exposed by the MDI parent.

Thanks,

Seth Rowe [MVP]

 

[BobRoyAce]

Thanks for the replies...they helped. Though I have heard of the
Observer Pattern, and am familiar with its uses, I don't really know
how to implement it in VS 2005, VB. Cmoya has given a start to the
coding and what's there makes sense to me. Does someone have full
sample code for a "MyBroadcaster" class? How would global object,
g_notifier, know which forms subscribe to which events? Wouldn't I
also need to code a "Listener" class? How and where would I write code
in each form's module to respond to each event? Any insights would be
appreciated.

 

[CMoya]

The broadcaster (g_notifier) wouldn't care who subscribes. In the simplest
and most versatile pattern ALL the child forms would receive the same
broadcast (that's why it's called a broadcast). It's up to the child forms
to decide if they're interested in it.

'in a child form
'set a local WithEvents reference to the global notifier object
Private WithEvents m_notifier As MyBroadcaster = g_notifier
'handle broadcast events
Private Sub m_notifier_Broadcast(ByVal sender As Object, ByVal data As
MyBroadcasterEventArgs) Handles m_notifier.Broadcast
Select Case data.Message
Case "SOMETHING"
'do something
Case "SOMETHING2"
'do something else
'Case Else
'ignore any other types of messages
End Select
End Sub

P.S.
Incidentally, this Broadcast paradigm is similar to the way Windows
communicates with windows.

 

[BobRoyAce]

Thanks for the additional insights. As I've been thinking about this
more, and if I understand things clearly, this way of doing things
would basically have every MDI child having the events broadcast to
them. Then, they would process the broadcast to see if they care.
Would it be better if things were done in such a way that different
forms "subscribe" only to the events that they care about. Then, the
broadcaster would broadcast a message to only those subscribers who
care. How would I implement something like this?

Perhaps it's not a big deal since the user will never have more than
6-10 windows open at a time, if that, anyway.

 

[rowe_newsgroups]

Thanks for the additional insights. As I've been thinking about this
more, and if I understand things clearly, this way of doing things
would basically have every MDI child having the events broadcast to
them. Then, they would process the broadcast to see if they care.
Would it be better if things were done in such a way that different
forms "subscribe" only to the events that they care about. Then, the
broadcaster would broadcast a message to only those subscribers who
care. How would I implement something like this?

Perhaps it's not a big deal since the user will never have more than
6-10 windows open at a time, if that, anyway.

Thats actually how the method I described to you works. The parent
form, usually through the use on interfaces, wires up the child form's
event handlers to the events that the child needs to hear. If a form
does not care about a certain event, then it won't be wired to that
form.

Thanks,

Seth Rowe [MVP]

 

[CMoya]

Events in .NET are lightweight and fast. Just think about all the events
your forms receieve in any one moment (mouse moves, repaints, etc) and how
events are bubbled up through many many controls and derived classes. You
could have a 100 child forms and not notice any performance hit using the
broadcast pattern.

You could do what Seth Rowe explained. Forget the broadcast pattern, have
the children implement an interface and the parent form would check to see
what interfaces they implement and call a method on the child or otherwise
wire up an event somehow. This accomplishes the same thing... but is not
really any better in performance. Either way yields the same negligable
performance hit (meaning none).