Objects should only be interfered with by public properties or event, however...

[opus]

I'm trying to stick to the above rule, but I'm running in a situation where I do need an advice.
It is the same code I posted before, however another question it.

I need to AddHandles during Runtime. Actually I do that from a module like:

For Each g As usrGram In MainForm.GramList
   AddHandler b.PingerPing, AddressOf g.Ping_zeichnen 'b as an ObjectType with a Event called PingerPing
Next

MainForm is the Starting Form which holds some UserControls (usrGram)
b are of Type ClassSomething, (as of now) neither a part of MainForm nor the UserControl.

I need each UserControl to react the Event PingerPing of each b, therefore I use the above AddHandler in the code which initially creates b. This code is in a module.
Because it is in a module the Sub "Ping_zeichnen" of the UserControl has to be Public, and that's the point.
The only way around this would be to make two events, one from b, on which a sub in the module is run, which raises an event on which the UserControl is already reacting.
The only other way I see to avoid the Public Sub is to use AddHandler in situation when there is already the Handler added/ RemoveHandler when the handler is already removed. Is there something that tells you if a specific handler is set or removed?

[Shaggy Hiker]

I don't understand what the problem is. I guess I don't understand the implications of the subject line. Could you explain the problem you are trying to avoid?

[opus]

The problem is that into my understanding the use of Public Procedures of Objects should be avoided. But that could easily be a misunderstanding from my side.

[Evil_Giraffe]

If every g on your form needs to react to the event from every b object, then you shouldn't wire them up directly. Instead, have one object that handles every b event, and that raises a corresponding event (with a reference to the b that raised the original event). Every g then handles the single event from the event aggregator object. I didn't appreciate that was what you were doing in your earlier thread.

As to your actual question, there is no issue with having a Public Sub on a UserControl, if that sub needs to be visible externally. Since you're controlling the wiring of events externally, you need something externally visible to use.

[opus]

Thanks again for your input.
I'll give your idea of an "Even Aggregator" some thoughts over the weekend.

Overall I'm trying to change my (so far) running application in a way that all objects are treated properly. Since I started that on in old VB6 days (around my joining date), and I learnered more and more over the time. So the application got more and more features. So there are a lot of parts that need some changes.

[Shaggy Hiker]

I have a series of classes that need to talk to each other via events. In my case, most of the classes are dynamically loaded from dlls, so the situation isn't quite the same, but the fact remains that these classes have to be able to raise events that other objects, including the main form, can respond to, as well as being able to respond to events raised by other objects. They certainly can't know about the other objects, since they are all dynamically loaded from dlls and can't mutually reference each other. Therefore, in a dll that is referenced by ALL others, including the main form, I put a single object that has a whole bunch of events, and a series of methods to call to raise each event. A single instance of this EventRaiser class is created when the app loads. Whenever an object is instantiated from one of the dlls, it is passed this instance of the EventRaiser. Therefore, all classes in the app hold a reference to the same, single, EventRaiser object. All classes can respond to events raised by the EventRaiser, and all classes can call a method in the EventRaiser to cause it to raise an event.

Something like that might work, though it may also be overkill.

[formlesstree4]

You might be able to get away with Custom Events

    Private ReadOnly m_BakedEvent As New List(Of EventHandler)()
    Custom Event Baked As EventHandler
        AddHandler(ByVal value As EventHandler)
            Console.WriteLine("Adding a new subscriber: {0}", value.Method)
            m_BakedEvent.Add(value)
        End AddHandler

        RemoveHandler(ByVal value As EventHandler)
            Console.WriteLine("Removing subscriber: {0}", value.Method)
            m_BakedEvent.Remove(value)
        End RemoveHandler

        RaiseEvent(ByVal sender As Object, ByVal e As EventArgs)
            Console.WriteLine("{0} is raising an event.", sender)
            For Each ev In m_BakedEvent
                ev.Invoke(sender, e)
            Next
        End RaiseEvent
    End Event

[opus]

The idea of an "event aggregator" (Evil Giraffe) or "EventRiser" (Shaggy Hiker) sounds promissing. I'M trying to get my head in that direction. It looksd as if such an Object could handle even more of "still be resolved" problems.

Thanks to everybody. I'll keep you informed about my progress.