Inheriting from EventArgs

[Roy Soltoff]

Two books, "Mastering Visual Basic.Net" and "Visual Basic.Net Developer's
Handbook" describe inheriting from System.EventArgs using a class similar
to:

Public Class MyEventArgs
Inherits System.EventArgs
Public Shared MyField As String
Public Sub New(Text As String)
Me.MyField = Text
End Sub
End Class

and using this in an event of the form:

Public Event MyEvent(sender As Object, e as MyEventArgs)

Using this technique works flawlessly in a VB.Net multi-project solution. VB
event handlers have no problem in accessing the static field. Unfortunately,
if this event is raised in a VB.Net component that is placed on a form in a
C# project, the C# delegate attached to the event does not see the MyField
item. My hunch is that the authors of these books use the assumption that
the MSDN documentation for the System.EventArgs class shows the public
fields (Empty) as a Public Shared (static declaration) so the assumption is
to declare all other fields that way. Just a hunch. The MSDN documentation
for the EventArgs class adds this comment, "Any public static (Shared in
Visual Basic) members of this type are thread safe. Any instance members are
not guaranteed to be thread safe."

Other references in MSDN that illustrate inheriting from EventArgs use a
private variable along with a public property (get:set) to access the
variable in question - similar to the following:

Public Class MyEventArgs
Inherits System.EventArgs
Dim MyField As String
Public Sub New(Text As String)
Me.MyField = Text
End Sub
Public Property TheField As String
Get
Return Me.MyField
End Get
Set (ByVal Value As String)
me.MyField = Value
End Set
End Class

There is absolutely no problem accessing the TheField property in the event
delegate from a C# form.

I have searched for a few days for some clues as to why the first form of
inheritance is suggested that does not surface the static members in C#.Net
but does in VB.Net, whereas the MSDN reference to inheritance uses
properties. Can anyone shed some light on the pros/cons of these two
techniques? Does this have to do with the comment in MSDN documentation
about threading safety?

[Herfried K. Wagner [MVP]]

"Roy Soltoff" <ra*************@community.nospam> schrieb:

Two books, "Mastering Visual Basic.Net" and "Visual Basic.Net Developer's
Handbook" describe inheriting from System.EventArgs using a class similar
to:

Public Class MyEventArgs
Inherits System.EventArgs
Public Shared MyField As String
Public Sub New(Text As String)
Me.MyField = Text
End Sub
End Class

Using a shared member doesn't make much sense here. You'd better use an
instance member, or even better, a property:

\\\
Public Class MyEventArgs
Inherits EventArgs

Private m_MyField As String

Public Property MyField() As String
Get
Return m_MyField
End Get
Set(ByVal Value As String)
m_MyField = Value
End Set
End Property

Public Sub New(ByVal MyField As String)
Me.MyField = MyField
End Sub
End Class
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Phill. W]

"Roy Soltoff" <ra*************@community.nospam> wrote in message
news:OC*************@TK2MSFTNGP12.phx.gbl...

Public Class MyEventArgs
Inherits System.EventArgs
Public Shared MyField As String
Public Sub New(Text As String)
Me.MyField = Text
End Sub
End Class
Why would MyField be /Shared/? Wouldn't you rather have each
instance of this class hold its /own/ value for this field? Anyway ...
Unfortunately, if this event is raised in a VB.Net component that is
placed on a form in a C# project, the C# delegate attached to the
event does not see the MyField item.

What is the signature of the delegate method?
It may try to use (the default) "MyEventArgs e", which will compile
perfectly well and even run (because MyEventArgs is derived from
EventArgs), but /won't/ be able to see the fields you've defined in
your SubType.

In the C# project, try "downCasting" the argument to the correct
type, something like:

MsgBox( ( (MyEventArgs)e ).MyField )

HTH,
Phill W.

[Chris Dunaway]

Roy Soltoff wrote:

event handlers have no problem in accessing the static field. Unfortunately,
if this event is raised in a VB.Net component that is placed on a form in a
C# project, the C# delegate attached to the event does not see the MyField
item. My hunch is that the authors of these books use the assumption that

Unlike VB.Net, C# does not allow you to access shared (static) members
from an instance of the class. You must use the class name.
Therefore, declaring your field as static is the reason you cannot see
it in C#.