An absence of IntelliSense in this situation

[Larry Lard]

My turn to ask a question :)

Consider this class hierarchy:

'code starts
Public Class CEventSource
Public Event MyEvent()
End Class

Public Class CBaseEventSourc eContainer
Public WithEvents ces As CEventSource

End Class

Public Class CDerivedEventSo urceContainer
Inherits CBaseEventSourc eContainer

End Class
'code ends

If I position myself in the body of CBaseEventSourc eContainer, 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 CBaseEventSourc eContainer:

Private Sub ces_MyEvent() Handles ces.MyEvent

End Sub

All nice and as expected.

However, if I position myself in the body of
CDerivedEventSo urceContainer - 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

[Richard Myers]

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" <la*******@hotm ail.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

My turn to ask a question :)

Consider this class hierarchy:

'code starts
Public Class CEventSource
Public Event MyEvent()
End Class

Public Class CBaseEventSourc eContainer
Public WithEvents ces As CEventSource

End Class

Public Class CDerivedEventSo urceContainer
Inherits CBaseEventSourc eContainer

End Class
'code ends

If I position myself in the body of CBaseEventSourc eContainer, 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 CBaseEventSourc eContainer:

Private Sub ces_MyEvent() Handles ces.MyEvent

End Sub

All nice and as expected.

However, if I position myself in the body of
CDerivedEventSo urceContainer - 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

[Larry Lard]

Thanks for your thoughts, I find that you are reinforcing what that
little voice inside my head has been telling me about the dubiousness
of my original design :)

Richard Myers wrote:

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 CBaseEventSourc eContainer
Private WithEvents m_ces As CEventSource

Private Sub MyEventHandler( sender as object, e as eventargs) Handles m_ces.MyEvent
OnMyEventOccura nce(e)
End Sub

Protected Overridable Sub OnMyEventOccura nce(e as eventargs)
' base event handling (possibly nothing at all)
End Sub
End Class

Public Class CDerivedEventSo urceContainer
Inherits CBaseEventSourc eContainer
Protected Overrides Sub OnMyEventOccura nce(e as Eventargs)
MyBase.OnMyEven tOccurance(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 CBaseEventSourc eContainer
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 CDerivedEventSo urceContainer
Inherits CBaseEventSourc eContainer

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" <la*******@hotm ail.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .
> My turn to ask a question :)
>
> Consider this class hierarchy:
>
> 'code starts
> Public Class CEventSource
> Public Event MyEvent()
> End Class
>
> Public Class CBaseEventSourc eContainer
> Public WithEvents ces As CEventSource
>
> End Class
>
> Public Class CDerivedEventSo urceContainer
> Inherits CBaseEventSourc eContainer
>
> End Class
> 'code ends
>
> If I position myself in the body of CBaseEventSourc eContainer,

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 CBaseEventSourc eContainer:
>
> Private Sub ces_MyEvent() Handles ces.MyEvent
>
> End Sub
>
> All nice and as expected.
>
> However, if I position myself in the body of
> CDerivedEventSo urceContainer - 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
>