Global events?

[gavio]

I don't really know how to call this...

Anyhow... I have two objects (for example, "A" and "B") of the same type/class. I have an event (for example, "Refreshed") in both objects. Is it possible, that when "Refreshed" fires in "A", it also fires in "B"?

Edit: forgot to mention - "A" and "B" don't "know" each other.

[Grimfort]

You can use AddHandler to link an object to an event, meaning more than one object can link to the same event. If/how this is done will depend on how far apart these events are in your project. Are they in the same project, are they created at runtime based upon certain conditions?

[gavio]

Yes. "A" and "B" are created at runtime and don't "know" each other (are objects created in totally different scenarios).

[gavio]

For example:

Public Class Form1
  Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    Dim A As New Form2
    Dim B As New Form2

    A.Text = "A"
    A.Show()
    B.Text = "B"
    B.Show()
  End Sub
End Class

Public Class Form2
  Public Event Refreshed()

  Public Sub Form2_Refreshed() Handles Me.Refreshed
    MsgBox(Me.Text)
  End Sub

  Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
    RaiseEvent Refreshed()
  End Sub
End Class

I want to fire "Refreshed" in "A" and "B" if you click "Button1" only in "A" or "B".

[Grimfort]

'In form1 click
AddHandler A.Refresh, AddressOf B.Form2_Refreshed

I'm assuming this is an example as there are other ways to get events around the place.

You could just create an interface that the form implements, then in your refresh you can call a global method that walks your forms looking for this interface then calls it.

[gavio]

I understand the "AddHandler" method. But. As I already mentioned - assume "A" and "B" don't know each other - neither do you. "A" and "B" are two objects created in different scenarios, different methods, different objects...

[Grimfort]

Heres another way

Module modExample

	Friend Event MyEvent()

	Friend Sub RaiseMyEvent()
		RaiseEvent MyEvent()
	End Sub


	Private Class TheClass

		Sub New()
			AddHandler modExample.MyEvent, AddressOf DoRefresh
		End Sub

		Sub DoRefresh()
			MsgBox("Did it!")
		End Sub

		Sub Clicked()
			RaiseMyEvent()
		End Sub

	End Class


	Sub Main()

		Dim Thing As New TheClass
		Dim OtherThing As New TheClass

		Thing.Clicked()

	End Sub


End Module

[techgnome]

Something somewhere needs to know about both A and B. If A raises a Refreshed event, something is handling that somewhere, right? In the Refreshed event handler of A... Call the Refresh method of B... Then, when A refreshes, and raises the event, B will refresh too.

-tg

[jmcilhinney]

What you're asking for is like a car manufacturer creating a car that, when a driver starts the engine in one car, the engine starts in another car too. Doesn't make sense, does it?

We'd need more specific information to know for sure but I'd guess that what you should be doing is declaring a Shared event. Just like any other Shared member, a Shared event belongs to the class rather than any specific instance of the class.

[Shaggy Hiker]

Let me give you an example that might help out.

I am currently working on a system that will have many modules that plug into the system. I don't currently know all the modules that will be created, so the design has to be flexible enough to handle a variety of modules being added at a later date for which I don't even know the purpose, let alone having any access to the code. I need events raised in the main module to be accessible to those modules. I think you would agree that code that is written knows less about code not even thought about than your A knows about your B. So how do I allow these future modules, whatever their purpose, to access the events raised by the pieces of the program currently being worked on?

What I did was to create a small class that has all the events, along with public methods that raise the events. I also created an interface that every module will need to implement. The interface itself is not all that important to this discussion, except that one of the methods that has to be called takes an instance of that EventRaiser class as an argument. Therefore, the main program creates a single instance of the EventRaiser class, which is then passed to every other class as it is created. Of course, since the EventRaiser is a class, all that is really being passed around is the address to that one single instance that was created when the main program started. There isn't an object being passed around, just an address (four bytes), but that means that every class is holding a reference to the same object. Therefore, every object can call any of the event raising methods in the EventRaiser class, and can handle any of the events raised by the EventRaiser.

The result is that all custom events in the program are raised by a single object, which all classes that need it have access to, and therefore, all classes can handle the events regardless of where they are raised.

You would need to do something like that. If A knows nothing of B, then they need a common bridge to communicate across, like my EventRaiser class. After all, when you handle an event (either with the Handles statement, or AddHandler), all you are doing is telling the object that raises the event that you have a method that the object should call when the event is raised. The object that raises the event takes that method and adds it to an internal list. When the event is raised, the object iterates through the list calling each method on the list in turn. Obviously, if A knows nothing of B, then A can't ask B to add a method to its list for any event because A doesn't know who to ask. By making one common class that both A and B have access to, and which raises all custom events as directed by either A or B, then you allow both A and B to receive events from the other without knowing about the existence of the other.

That seems a bit muddled to me, but it's as clear as I can get at the moment.