"Larry Lard" <larryl***@hotmail.com> wrote in message
news:1113578437.895171.313090@z14g2000cwz.googlegroups.com...
> My turn to ask a question :)
>
> Consider this class hierarchy:
>
> 'code starts
> Public Class CEventSource
>     Public Event MyEvent()
> End Class
>
> Public Class CBaseEventSourceContainer
>     Public WithEvents ces As CEventSource
>
> End Class
>
> Public Class CDerivedEventSourceContainer
>     Inherits CBaseEventSourceContainer
>
> End Class
> 'code ends
>
> If I position myself in the body of CBaseEventSourceContainer, the
> 'object' dropdown at the top left of the code window correctly offers
> me the ces object; if I select it, the 'procedures' dropdown at the top
> right of the code window then offers me MyEvent, and selecting that
> creates this code snippet within CBaseEventSourceContainer:
>
>     Private Sub ces_MyEvent() Handles ces.MyEvent
>
>     End Sub
>
> All nice and as expected.
>
> However, if I position myself in the body of
> CDerivedEventSourceContainer - which, like its parent, has a WithEvents
> member called ces - I am not offered ces in the 'object' dropdown :( If
> I create a Sub line and type "Handles ", at that point I can ctrl+space
> and be offered ces, so VS *does* know about it. But  it will not create
> the skeleton for me.
>
> Not a showstopper I know, but any thoughts?
>
> --
> Larry Lard
> Replies to group please
>

> As you say you still have access to the base class event source so
there no
> actual restrictions to using this variable. However i think VS.Net is
> working along the lines of best practise. You will also note that if
you
> inherit from Stream (or any other base class) you cannot directly
WthEvents
> their base class variables either. The reason for this I assume is
OOP and
> the principal of encapsulation.
>
> You have declared your event source variable in public scope in the
base
> class. This is ugly to begin with. Its best declared private then
wrapped
> in a property.
>
> If additional processing is required within/internal to the derived
class
> in addition to base class handling of the event then the base class
should
> provide an overridable method (possibly protected) that derived
classes can
> use to respond to the event source. This would obviously be called by
the
> base class when the event source fired.
>
> If additional processing is required external to the event source
container
> and the listeners for this event have no way of registering at the
primary
> event source CEventSource, then an additonal event could be created
in one
> of the container classes at the most appropriately derived level.
>
> Basically VS.Net will allow us to write poorly designed class
libraries but
> it doesn;t go out of its way to ensure that we do. Which makes sense
from
> Microsofts point of view because crap code = crap products = crap
platform
> perception = diminishing and/or negative growth.
>
> Richard
>
>
> "Larry Lard" <larryl***@hotmail.com> wrote in message
> news:1113578437.895171.313090@z14g2000cwz.googlegroups.com...
> > My turn to ask a question :)
> >
> > Consider this class hierarchy:
> >
> > 'code starts
> > Public Class CEventSource
> >     Public Event MyEvent()
> > End Class
> >
> > Public Class CBaseEventSourceContainer
> >     Public WithEvents ces As CEventSource
> >
> > End Class
> >
> > Public Class CDerivedEventSourceContainer
> >     Inherits CBaseEventSourceContainer
> >
> > End Class
> > 'code ends
> >
> > If I position myself in the body of CBaseEventSourceContainer, the
> > 'object' dropdown at the top left of the code window correctly
offers
> > me the ces object; if I select it, the 'procedures' dropdown at the
top
> > right of the code window then offers me MyEvent, and selecting that
> > creates this code snippet within CBaseEventSourceContainer:
> >
> >     Private Sub ces_MyEvent() Handles ces.MyEvent
> >
> >     End Sub
> >
> > All nice and as expected.
> >
> > However, if I position myself in the body of
> > CDerivedEventSourceContainer - which, like its parent, has a
WithEvents
> > member called ces - I am not offered ces in the 'object' dropdown
:( If
> > I create a Sub line and type "Handles ", at that point I can
ctrl+space
> > and be offered ces, so VS *does* know about it. But  it will not
create
> > the skeleton for me.
> >
> > Not a showstopper I know, but any thoughts?
> >
> > --
> > Larry Lard
> > Replies to group please
> >

>
> 'code starts
> Public Class CEventSource
>     Public Event MyEvent()
> End Class
>
> Public Class CBaseEventSourceContainer
>     Private WithEvents m_ces As CEventSource
>     Public Property ces As CEventSource 'plus usual property stuff
>
>     Protected Sub MyEventHandler() Handles m_ces.MyEvent
>         ' base event handling (possibly nothing at all)
>     End Sub
>
> End Class
>
> Public Class CDerivedEventSourceContainer
>     Inherits CBaseEventSourceContainer
>
>     Private Overrides Sub MyEventHandler() Handles m_ces.MyEvent
>         ' specialised event handling
>     End Sub
>
> End Class
> 'code ends
>
>
>
>
> Richard Myers wrote:
> > As you say you still have access to the base class event source so
> there no
> > actual restrictions to using this variable. However i think VS.Net is
> > working along the lines of best practise. You will also note that if
> you
> > inherit from Stream (or any other base class) you cannot directly
> WthEvents
> > their base class variables either. The reason for this I assume is
> OOP and
> > the principal of encapsulation.
> >
> > You have declared your event source variable in public scope in the
> base
> > class. This is ugly to begin with. Its best declared private then
> wrapped
> > in a property.
> >
> > If additional processing is required within/internal to the derived
> class
> > in addition to base class handling of the event then the base class
> should
> > provide an overridable method (possibly protected) that derived
> classes can
> > use to respond to the event source. This would obviously be called by
> the
> > base class when the event source fired.
> >
> > If additional processing is required external to the event source
> container
> > and the listeners for this event have no way of registering at the
> primary
> > event source CEventSource, then an additonal event could be created
> in one
> > of the container classes at the most appropriately derived level.
> >
> > Basically VS.Net will allow us to write poorly designed class
> libraries but
> > it doesn;t go out of its way to ensure that we do. Which makes sense
> from
> > Microsofts point of view because crap code = crap products = crap
> platform
> > perception = diminishing and/or negative growth.
> >
> > Richard
> >
> >
> > "Larry Lard" <larryl***@hotmail.com> wrote in message
> > news:1113578437.895171.313090@z14g2000cwz.googlegroups.com...
> > > My turn to ask a question :)
> > >
> > > Consider this class hierarchy:
> > >
> > > 'code starts
> > > Public Class CEventSource
> > >     Public Event MyEvent()
> > > End Class
> > >
> > > Public Class CBaseEventSourceContainer
> > >     Public WithEvents ces As CEventSource
> > >
> > > End Class
> > >
> > > Public Class CDerivedEventSourceContainer
> > >     Inherits CBaseEventSourceContainer
> > >
> > > End Class
> > > 'code ends
> > >
> > > If I position myself in the body of CBaseEventSourceContainer, the
> > > 'object' dropdown at the top left of the code window correctly
> offers
> > > me the ces object; if I select it, the 'procedures' dropdown at the
> top
> > > right of the code window then offers me MyEvent, and selecting that
> > > creates this code snippet within CBaseEventSourceContainer:
> > >
> > >     Private Sub ces_MyEvent() Handles ces.MyEvent
> > >
> > >     End Sub
> > >
> > > All nice and as expected.
> > >
> > > However, if I position myself in the body of
> > > CDerivedEventSourceContainer - which, like its parent, has a
> WithEvents
> > > member called ces - I am not offered ces in the 'object' dropdown
> :( If
> > > I create a Sub line and type "Handles ", at that point I can
> ctrl+space
> > > and be offered ces, so VS *does* know about it. But  it will not
> create
> > > the skeleton for me.
> > >
> > > Not a showstopper I know, but any thoughts?
> > >
> > > --
> > > Larry Lard
> > > Replies to group please
> > >
>

> >
> > So would this be better:
>
> Well it depends entirley on use. If derived classes dont need access
to the
> event source and only need to know if and when it fires an event then
you
> might well drop the property altogether or alternatively scope it at
> Protected (if only derived classes need access to it). If its just
about
> handling the event when fired then i'd be more inclined to code it up
in
> the same manner as the framework uses.
>
>  Public Class CEventSource
>      Public Event MyEvent()
>  End Class
>
> Public Class CBaseEventSourceContainer
>      Private WithEvents m_ces As CEventSource
>
>      Private Sub MyEventHandler(sender as object, e as eventargs)
Handles
> m_ces.MyEvent
>          OnMyEventOccurance(e)
>     End Sub
>
>     Protected Overridable Sub OnMyEventOccurance(e as eventargs)
>         ' base event handling (possibly nothing at all)
>     End Sub
> End Class
>
> Public Class CDerivedEventSourceContainer
>      Inherits CBaseEventSourceContainer
>
>
>     Protected Overrides Sub OnMyEventOccurance(e as Eventargs)
>         MyBase.OnMyEventOccurance(e)
>         ' specialised event handling
>     End Sub
>  End Class
>
> I dont like the style of *handling*  internal events or events fired
by by
> base class variables. I think its ugly and a poor way to design an
OOP
> class library. Inheritence and overriding provide a much cleaner
interface
> and is also more consistent with .NET framework.
>
> Richard
>
> >
> > 'code starts
> > Public Class CEventSource
> >     Public Event MyEvent()
> > End Class
> >
> > Public Class CBaseEventSourceContainer
> >     Private WithEvents m_ces As CEventSource
> >     Public Property ces As CEventSource 'plus usual property stuff
> >
> >     Protected Sub MyEventHandler() Handles m_ces.MyEvent
> >         ' base event handling (possibly nothing at all)
> >     End Sub
> >
> > End Class
> >
> > Public Class CDerivedEventSourceContainer
> >     Inherits CBaseEventSourceContainer
> >
> >     Private Overrides Sub MyEventHandler() Handles m_ces.MyEvent
> >         ' specialised event handling
> >     End Sub
> >
> > End Class
> > 'code ends
> >
> >
> >
> >
> > Richard Myers wrote:
> > > As you say you still have access to the base class event source
so
> > there no
> > > actual restrictions to using this variable. However i think

> > > working along the lines of best practise. You will also note that
if
> > you
> > > inherit from Stream (or any other base class) you cannot directly
> > WthEvents
> > > their base class variables either. The reason for this I assume
is
> > OOP and
> > > the principal of encapsulation.
> > >
> > > You have declared your event source variable in public scope in
the
> > base
> > > class. This is ugly to begin with. Its best declared private then
> > wrapped
> > > in a property.
> > >
> > > If additional processing is required within/internal to the
derived
> > class
> > > in addition to base class handling of the event then the base
class
> > should
> > > provide an overridable method (possibly protected) that derived
> > classes can
> > > use to respond to the event source. This would obviously be
called by
> > the
> > > base class when the event source fired.
> > >
> > > If additional processing is required external to the event source
> > container
> > > and the listeners for this event have no way of registering at
the
> > primary
> > > event source CEventSource, then an additonal event could be
created
> > in one
> > > of the container classes at the most appropriately derived level.
> > >
> > > Basically VS.Net will allow us to write poorly designed class
> > libraries but
> > > it doesn;t go out of its way to ensure that we do. Which makes
sense
> > from
> > > Microsofts point of view because crap code = crap products = crap
> > platform
> > > perception = diminishing and/or negative growth.
> > >
> > > Richard
> > >
> > >
> > > "Larry Lard" <larryl***@hotmail.com> wrote in message
> > > news:1113578437.895171.313090@z14g2000cwz.googlegroups.com...
> > > > My turn to ask a question :)
> > > >
> > > > Consider this class hierarchy:
> > > >
> > > > 'code starts
> > > > Public Class CEventSource
> > > >     Public Event MyEvent()
> > > > End Class
> > > >
> > > > Public Class CBaseEventSourceContainer
> > > >     Public WithEvents ces As CEventSource
> > > >
> > > > End Class
> > > >
> > > > Public Class CDerivedEventSourceContainer
> > > >     Inherits CBaseEventSourceContainer
> > > >
> > > > End Class
> > > > 'code ends
> > > >
> > > > If I position myself in the body of CBaseEventSourceContainer,
the
> > > > 'object' dropdown at the top left of the code window correctly
> > offers
> > > > me the ces object; if I select it, the 'procedures' dropdown at
the
> > top
> > > > right of the code window then offers me MyEvent, and selecting
that
> > > > creates this code snippet within CBaseEventSourceContainer:
> > > >
> > > >     Private Sub ces_MyEvent() Handles ces.MyEvent
> > > >
> > > >     End Sub
> > > >
> > > > All nice and as expected.
> > > >
> > > > However, if I position myself in the body of
> > > > CDerivedEventSourceContainer - which, like its parent, has a
> > WithEvents
> > > > member called ces - I am not offered ces in the 'object'
dropdown
> > :( If
> > > > I create a Sub line and type "Handles ", at that point I can
> > ctrl+space
> > > > and be offered ces, so VS *does* know about it. But  it will
not
> > create
> > > > the skeleton for me.
> > > >
> > > > Not a showstopper I know, but any thoughts?
> > > >
> > > > --
> > > > Larry Lard
> > > > Replies to group please
> > > >
> >