Raise base class event from derived child class - not possible

[DolphinPC]

Hello,

I posted on the DotNet reddit with zero feedback. Is it impossible to raise a base class event from a derived (child class that inherits base) class in VB?

This is a trivial request and I am unable to get a subscriber of the event to receive the event.

Many posts online and through MS Docs says to build a base class wrapper that protected sub to call the base class event. This didn't work either. So I tried that.

Consider the following example
(Apologies I'm on mobile - no way to add code tags?


Code Example:

    Public Class ParentTest
        Public Event OnEventFire()
      
      
        Protected Sub RaiseParentEvent() 'helper sub? See MS article.
            RaiseEvent OnEventFire()
            Debug.Print("Parent event was raised.")
      
        End Sub
      
  
        Public Class ChildTest
            Inherits ParentTest
            Sub EventWasTriggered()
      
                'call parent helper sub
                RaiseParentEvent()
      
            End Sub
      
        End Class
    End Class

    Class MainProgram
        Private WithEvents parent As New ParentTest
      
      
        Sub RunProgram()
      
            Dim child As New ParentTest.ChildTest
      
            'subscribe to the parent event
            AddHandler parent.OnEventFire, AddressOf ReceiveEvent
      
      
            'trigger event...
            child.EventWasTriggered()
      
        End Sub
      
        'trigger
        Private Sub ReceiveEvent() Handles parent.OnEventFire
            MsgBox("FIRE!")  '<---- never fires when RunProgram() is called!
        End Sub
    End Class

 

[jmcilhinney]

By the way, there's no good reason for that ChildTest class to be declared inside the ParentTest class. There's rarely any good reason to nest classes and there certainly isn't here. That you have done it that way may actually be part of the reason that you are confused. Separate the two declarations and then it may be more obvious that they are actually distinct classes.

 

[DolphinPC]

By the way, there's no good reason for that ChildTest class to be declared inside the ParentTest class. There's rarely any good reason to nest classes and there certainly isn't here. That you have done it that way may actually be part of the reason that you are confused. Separate the two declarations and then it may be more obvious that they are actually distinct classes.

A small reach given you know nothing about the context of the application. The child class itself is a very tiny member inside the parent and nesting it is entirely appropriate. The child wouldn't even be a separate class, had a function in the parent class not required it to be.

You seem to have a fundamental lack of understanding of how OOP works. It's not so unusual when starting out. Many people have trouble mapping abstract concepts of types and objects to the real world. Lets try an example that is a bit more like the physical world that might make it easier.

Spare me the patronization. This was merely an oversight in my code. Your analogy does a poor job equating to my situation, as you mention nothing about the parent of any of the button class. Nevertheless, I found the mistake in my line of thinking and the problem is solved.

 

[cjard]

you know nothing about the context of the application

We only know what you tell us, and confused, contrived, broken examples don't tell us much. Don't then attack us for pointing out that it's confused/unworkable; you wrote it!

tiny member inside the parent and nesting it is entirely appropriate

I wouldn't say class size is a determining factor as to whether a nested class should be used and I do agree that of the limited cases where nested classes are appropriate, this doesn't appear to be one of them

you mention nothing about the parent of any of the button class

jmc did, actually.. The button Click event is declared on the parent, not the child, but the child can raise it easily because a child is a parent. The Click event is typically subscribed to externally, as a way for the external subscriber to know it needs to run some code. That external subscriber would have reference to the instance raising the event, or it could be given it as part of the event. By going full circle and making an inner child class do the work normally done by an external unrelated class you might well have created a recipe for confusion..

For better advice in future, please dispense with the contrived examples and tell us the actual classes you're dealing with. It helps us understand your context and makes your life easier back translating our advice to solve your actual problem

 

[jmcilhinney]

A small reach given you know nothing about the context of the application. The child class itself is a very tiny member inside the parent and nesting it is entirely appropriate.

I'm going to have to disagree. Nesting classes is something that should rarely be done at all. Making the nested class public should be done even less often. Having the nested class inherit the outer class seems pretty mad to me. I can't imagine a situation where that would be the best design.

Your analogy does a poor job equating to my situation, as you mention nothing about the parent of any of the button class.

It's a perfect analogy. You have ChildTest inheriting ParentTest and its OnEventFire event. I had RedButton inheriting Button and its Click event. It seems to me that you have taken offence and are thus determined to find fault with anything I said, to your own detriment.