By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,990 Members | 2,324 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,990 IT Pros & Developers. It's quick & easy.

Serialization - Pesky VB's Event implementation.

P: n/a
Heya All,

Sorry, but I think it's about time for a monkey-ramble.

I've just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the <Serialized()> attribute on the class
and away you go. As Homer would say - "D'Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can't apply the <NonSerialized> attribute to the little rascals.
The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right
along with ObjectA.

If you don't believe me, go ahead and try it. Create a serializable class
with an event and some private fields. Create a form an declare an instance
of the class and handle the event (with withevents or addhandler - doesn't
matter). Now try and serialize the instance of the class - you'll get a
serialization exception because the form (not the class you're trying to
serialize) isn't serializable!

Fair enough, you may say. This shouldn't be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can't
even do it reliably (because I have no way of telling who has attached to my
events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of objects
(say Trigger objects that fire an event periodically). The Collection of
triggers has it's own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a trigger's
event when adding it to the collection. Now, guess what happens when you try
and serialize the collection - it works! WooHoo!. Now try and deserialize
it. Again "D'Oh". This time you get an exception because you can't
deserialize a delegate to a private method for security reasons!

In my travels I've had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and their
pros and cons:

1) Implement ISerializable and don't serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don't allow you to specify surrogates, so you end up re-writing
them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It's a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I'm mighty fed up with events. I realize that the fact that
the <NonSerialized> attribute can't be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I'm off to learn C# ;)

Cheers,

Trev.
Nov 20 '05 #1
Share this Question
Share on Google+
27 Replies


P: n/a
Codemonkey,
As you can see. I'm mighty fed up with events. I realize that the fact that the <NonSerialized> attribute can't be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway? As soon as they say you cannot, someone will come up with a valid reason ;-)
1) Implement ISerializable and don't serialize the events. This is the one I've been using as I needed ISerializable for other purposes
and lucked out on the event part of it ;-)
2) Implement an ISerializationSurrogate to strip out the events: I consider this a variation of #1, only in a second class.
3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes Reflection or SerializationServices? I was under the impression you can use
SerializationServices from the current class. Granted you may need to trim
the array that SerializationServices.GetSerializableMembers returned,
however I would think that would be easier then implementing all the logic
yourself...

Hope this helps,
Jay

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:Oe**************@TK2MSFTNGP12.phx.gbl... Heya All,

Sorry, but I think it's about time for a monkey-ramble.

I've just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the <Serialized()> attribute on the class and away you go. As Homer would say - "D'Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can't apply the <NonSerialized> attribute to the little rascals.
The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right
along with ObjectA.

If you don't believe me, go ahead and try it. Create a serializable class
with an event and some private fields. Create a form an declare an instance of the class and handle the event (with withevents or addhandler - doesn't
matter). Now try and serialize the instance of the class - you'll get a
serialization exception because the form (not the class you're trying to
serialize) isn't serializable!

Fair enough, you may say. This shouldn't be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can't
even do it reliably (because I have no way of telling who has attached to my events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of objects (say Trigger objects that fire an event periodically). The Collection of
triggers has it's own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a trigger's event when adding it to the collection. Now, guess what happens when you try and serialize the collection - it works! WooHoo!. Now try and deserialize
it. Again "D'Oh". This time you get an exception because you can't
deserialize a delegate to a private method for security reasons!

In my travels I've had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and their pros and cons:

1) Implement ISerializable and don't serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don't allow you to specify surrogates, so you end up re-writing
them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It's a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I'm mighty fed up with events. I realize that the fact that the <NonSerialized> attribute can't be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I'm off to learn C# ;)

Cheers,

Trev.

Nov 20 '05 #2

P: n/a
Yeah, I noticed that too...
I have a class that need to be serialised, and another class with events
not to be serialised
I have a reference of the class with events in first class and I have to
detach any event handler before serialisation ... the opposite to your
issue.... ugly thing
--
Cheers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:Oe**************@TK2MSFTNGP12.phx.gbl...
Heya All,

Sorry, but I think it's about time for a monkey-ramble.

I've just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the <Serialized()> attribute on the class and away you go. As Homer would say - "D'Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can't apply the <NonSerialized> attribute to the little rascals.
The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right
along with ObjectA.

If you don't believe me, go ahead and try it. Create a serializable class
with an event and some private fields. Create a form an declare an instance of the class and handle the event (with withevents or addhandler - doesn't
matter). Now try and serialize the instance of the class - you'll get a
serialization exception because the form (not the class you're trying to
serialize) isn't serializable!

Fair enough, you may say. This shouldn't be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can't
even do it reliably (because I have no way of telling who has attached to my events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of objects (say Trigger objects that fire an event periodically). The Collection of
triggers has it's own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a trigger's event when adding it to the collection. Now, guess what happens when you try and serialize the collection - it works! WooHoo!. Now try and deserialize
it. Again "D'Oh". This time you get an exception because you can't
deserialize a delegate to a private method for security reasons!

In my travels I've had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and their pros and cons:

1) Implement ISerializable and don't serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don't allow you to specify surrogates, so you end up re-writing
them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It's a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I'm mighty fed up with events. I realize that the fact that the <NonSerialized> attribute can't be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I'm off to learn C# ;)

Cheers,

Trev.

Nov 20 '05 #3

P: n/a
Hi CodeMonkey,

This is a great idea for a future product enhancement. I'd recommend that
you forward the recommendation to the Microsoft Wish Program:

Microsoft offers several ways for you to send comments or suggestions about
Microsoft products. If you have suggestions for product enhancements that
you would like to see in future versions of Microsoft products, please
contact us using one of the methods listed later in this article.

Let us know how we can improve our products.

Product Enhancement suggestions can include:

" Improvements on existing products.
" Suggestions for additional features.
" Ways to make products easier to use.

World Wide Web - To send a comment or suggestion via the Web, use one of
the following methods:

" In Internet Explorer 6, click Send Feedback on the Help menu and then
click the link in the Product Suggestion section of the page that appears.
" In Windows XP, click Help and Support on the Start menu. Click Send your
feedback to Microsoft, and then fill out the Product Suggestion page that
appears.
" Visit the following Microsoft Web site: http://www.microsoft.com/ms.htm
" Click Microsoft.com Guide in the upper-right corner of the page and then
click Contact Us . Click the link in the Product Suggestion section of the
page that appears.
" Visit the following Microsoft Product Feedback Web site:
"http://register.microsoft.com/mswish/suggestion.asp" and then complete and
submit the form.

E-mail - To send comments or suggestions via e-mail, use the following
Microsoft Wish Program e-mail address, ms****@microsoft.com.
FAX - To send comments or suggestions via FAX, use the following Microsoft
FAX number, (425) 936-7329.

Each product suggestion is read by a member of our product feedback team,
classified for easy access, and routed to the product or service team to
drive Microsoft product and/or service improvements. Because we receive an
abundance of suggestions (over 69,000 suggestions a year!) we can't
guarantee that each request makes it into a final product or service. But
we can tell you that each suggestion has been received and is being
reviewed by the team that is most capable of addressing it.

All product or service suggestions received become the sole property of
Microsoft. Should a suggestion be implemented, Microsoft is under no
obligation to provide compensation.
Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 20 '05 #4

P: n/a
Hi,

If you have concern on this issue ,please post here.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 20 '05 #5

P: n/a
You replyed for me?

Yes, I'm annoyed about the fact that for a class to be serialized, it cant
have mapped event hndlers in a class not serialisable
I whould like to decide myself if a class I design should attempt to
serialise an object that handle my events.

--
Cheers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

"Peter Huang" <v-******@online.microsoft.com> wrote in message
news:6h**************@cpmsftngxa07.phx.gbl...
Hi,

If you have concern on this issue ,please post here.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 20 '05 #6

P: n/a
> > 2) Implement an ISerializationSurrogate to strip out the events:
I consider this a variation of #1, only in a second class.
Yeah, with the exception that you can't use surrogates with the built in
soap or binary formatter.
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?

As soon as they say you cannot, someone will come up with a valid reason

;-)

Well I have a pretty valid reason for *not* doing it. The option to do it or
not to do it would have been nice. <NonSerialized> - *spit* :)
3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes

Reflection or SerializationServices? I was under the impression you can

use SerializationServices from the current class. Granted you may need to trim
the array that SerializationServices.GetSerializableMembers returned,
however I would think that would be easier then implementing all the logic
yourself...


D'Oh. Now you tell me! I actually went ahead and used reflection to do it.
It worked out pretty well, but I haven't performance tested it. Basically, I
used the following algorithm to get the serializable fields:

1. Get all the Fields in this object (and derived objects) using reflection
2. Filter out those with <NonSerialized> and delegate types.
3. Add all the values of the fields to the SerializationInfo object.

Guess I was reinventing the wheel ;)

Cheers for listening to the ramble

Trev.
Nov 20 '05 #7

P: n/a
I have a reference of the class with events in first class and I have to
detach any event handler before serialisation ...


Good idea. Never though of this myself, but I still don't like my logic
spread over two classes, especially because of an apparent shortfall in the
language (namely <NonSerialized>).

Thanks for the idea,

Trev.
Nov 20 '05 #8

P: n/a
Thanks, Peter.
Because we receive an
abundance of suggestions
(over 69,000 suggestions a year!)
Humm. Let me see if I can bring that number up a bit ;)

Trev.

"Peter Huang" <v-******@online.microsoft.com> wrote in message
news:6h**************@cpmsftngxa07.phx.gbl... Hi,

If you have concern on this issue ,please post here.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 20 '05 #9

P: n/a
>I was under the impression you can use
SerializationServices from the current
class. Granted you may need to trim
the array that SerializationServices.GetSerializableMembers


I looked for SerializationServices and couldn't find it. Did you mean
FormatterServices instead?

Looking at the FormatterServices.GetSerializableMembers Method, I guess I
could use it in my serializable class by filtering out delegates. If I get
around to a proper implementation, I'll post a new thread with the source,
just in case others are interested.

Cheers again,

Trev.

Nov 20 '05 #10

P: n/a
Trev,
2) Implement an ISerializationSurrogate to strip out the events: I consider this a variation of #1, only in a second class.


Yeah, with the exception that you can't use surrogates with the built in
soap or binary formatter.

Can you explain further? The sample in the MSDN mag articles (third article
below, figure 2) uses ISerializationSurrogate with the SOAP formatter! I
would expect the same sample would work with the Binary formatter. Are you
certain you implemented it correctly & got it registered with the surrogate
selector & formatter correctly? I admit I have not played with
ISerializationSurrogate so I cannot say for certain either way. However its
purpose in life is to support the soap & binary formatters. Are you thinking
it doesn't work with the XmlFormatter? As I understand the XmlFormatter does
"its own thing" (too many formatters, not enough clear information).
D'Oh. Now you tell me! I actually went ahead and used reflection to do it. You have looked at the following three part MSDN mag articles?

http://msdn.microsoft.com/msdnmag/issues/02/04/net/
http://msdn.microsoft.com/msdnmag/issues/02/07/net/
http://msdn.microsoft.com/msdnmag/issues/02/09/net/

They cover lightly cover FormatterServices (not SerializationServices, it
was late), detailed cover ISerializationSurrogate, and mostly cover every
thing else about serialization.

Hope this helps
Jay

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eC**************@TK2MSFTNGP12.phx.gbl...
2) Implement an ISerializationSurrogate to strip out the events:

I consider this a variation of #1, only in a second class.


Yeah, with the exception that you can't use surrogates with the built in
soap or binary formatter.
anybody think of a valid reason why you would want to serialize an event (and all objects that handle its events) anyway?

As soon as they say you cannot, someone will come up with a valid reason

;-)

Well I have a pretty valid reason for *not* doing it. The option to do it

or not to do it would have been nice. <NonSerialized> - *spit* :)
3) Implement ISerializable in a base class and use reflection to get all private fields in derived classes Reflection or SerializationServices? I was under the impression you can

use
SerializationServices from the current class. Granted you may need to trim the array that SerializationServices.GetSerializableMembers returned,
however I would think that would be easier then implementing all the logic yourself...


D'Oh. Now you tell me! I actually went ahead and used reflection to do it.
It worked out pretty well, but I haven't performance tested it. Basically,

I used the following algorithm to get the serializable fields:

1. Get all the Fields in this object (and derived objects) using reflection 2. Filter out those with <NonSerialized> and delegate types.
3. Add all the values of the fields to the SerializationInfo object.

Guess I was reinventing the wheel ;)

Cheers for listening to the ramble

Trev.

Nov 20 '05 #11

P: n/a
Trev,
Yes FormatterServices not SerializationServices, it was late.

See my other post for more details.

Jay

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:OO**************@tk2msftngp13.phx.gbl...
I was under the impression you can use
SerializationServices from the current
class. Granted you may need to trim
the array that SerializationServices.GetSerializableMembers


I looked for SerializationServices and couldn't find it. Did you mean
FormatterServices instead?

Looking at the FormatterServices.GetSerializableMembers Method, I guess I
could use it in my serializable class by filtering out delegates. If I get
around to a proper implementation, I'll post a new thread with the source,
just in case others are interested.

Cheers again,

Trev.

Nov 20 '05 #12

P: n/a
On Wed, 14 Jan 2004 10:45:14 -0000, Codemonkey wrote:

Humm. Let me see if I can bring that number up a bit ;)


It would be nice to get the new version *this* year sometime! :)

--
Chris

To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.
Nov 20 '05 #13

P: n/a
> It would be nice to get the new version *this* year sometime! :)

Yeah, before I have to renew my MSDN subscription for next year to get it ;)
Nov 20 '05 #14

P: n/a
Yeah, with the exception that you can't use surrogates with the built in
soap or binary formatter. Can you explain further?


Sorry for making such a general assumption. I was referring to my
experiences with Serialization and Remoting with Soap and Binary Formatters.
There was a discussion I started a long time ago in the *.framework.remoting
and *.distributed_apps groups that explained this problem. I can't find all
the articles right now, but try http://tinyurl.com/2pxkp for a start. I seem
to remember that the problem was something about not being able to set the
formatters up to use a surrogate selector within the remoting framework.
Again, sorry for making the generalization about serialization.

You have looked at the following three part MSDN mag articles?
Yeah, you posted those to me before in the thread above, but I totally
forgot about them. Cheers for the reminder.

Trev.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... Trev,
> 2) Implement an ISerializationSurrogate to strip out the events:
I consider this a variation of #1, only in a second class.
Yeah, with the exception that you can't use surrogates with the built in
soap or binary formatter.

Can you explain further? The sample in the MSDN mag articles (third

article below, figure 2) uses ISerializationSurrogate with the SOAP formatter! I
would expect the same sample would work with the Binary formatter. Are you
certain you implemented it correctly & got it registered with the surrogate selector & formatter correctly? I admit I have not played with
ISerializationSurrogate so I cannot say for certain either way. However its purpose in life is to support the soap & binary formatters. Are you thinking it doesn't work with the XmlFormatter? As I understand the XmlFormatter does "its own thing" (too many formatters, not enough clear information).
D'Oh. Now you tell me! I actually went ahead and used reflection to do it.
You have looked at the following three part MSDN mag articles?

http://msdn.microsoft.com/msdnmag/issues/02/04/net/
http://msdn.microsoft.com/msdnmag/issues/02/07/net/
http://msdn.microsoft.com/msdnmag/issues/02/09/net/

They cover lightly cover FormatterServices (not SerializationServices, it
was late), detailed cover ISerializationSurrogate, and mostly cover every
thing else about serialization.

Hope this helps
Jay

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eC**************@TK2MSFTNGP12.phx.gbl... > 2) Implement an ISerializationSurrogate to strip out the events:
I consider this a variation of #1, only in a second class.
Yeah, with the exception that you can't use surrogates with the built in
soap or binary formatter.
> anybody think of a valid reason why you would want to serialize an event > (and all objects that handle its events) anyway?
As soon as they say you cannot, someone will come up with a valid
reason
;-)

Well I have a pretty valid reason for *not* doing it. The option to do it or
not to do it would have been nice. <NonSerialized> - *spit* :)
> 3) Implement ISerializable in a base class and use reflection to get
all > private fields in derived classes
Reflection or SerializationServices? I was under the impression you
can use
SerializationServices from the current class. Granted you may need to trim the array that SerializationServices.GetSerializableMembers returned,
however I would think that would be easier then implementing all the logic yourself...


D'Oh. Now you tell me! I actually went ahead and used reflection to do

it. It worked out pretty well, but I haven't performance tested it.

Basically, I
used the following algorithm to get the serializable fields:

1. Get all the Fields in this object (and derived objects) using

reflection
2. Filter out those with <NonSerialized> and delegate types.
3. Add all the values of the fields to the SerializationInfo object.

Guess I was reinventing the wheel ;)

Cheers for listening to the ramble

Trev.


Nov 20 '05 #15

P: n/a
Trev,
That's right Remoting you cannot use surrogates (at least easily). ;-)
Yeah, you posted those to me before in the thread above, but I totally
forgot about them. Cheers for the reminder. Yep they are my Serialization FAQ, I loose track who I share them with...

Jay

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...
Yeah, with the exception that you can't use surrogates with the built in soap or binary formatter. Can you explain further?


Sorry for making such a general assumption. I was referring to my
experiences with Serialization and Remoting with Soap and Binary

Formatters. There was a discussion I started a long time ago in the *.framework.remoting and *.distributed_apps groups that explained this problem. I can't find all the articles right now, but try http://tinyurl.com/2pxkp for a start. I seem to remember that the problem was something about not being able to set the
formatters up to use a surrogate selector within the remoting framework.
Again, sorry for making the generalization about serialization.

You have looked at the following three part MSDN mag articles?


Yeah, you posted those to me before in the thread above, but I totally
forgot about them. Cheers for the reminder.

Trev.

<<snip>>
Nov 20 '05 #16

P: n/a
Hi Critus,

So far, I think you may try Codemonkey's suggestions in his original post.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 20 '05 #17

P: n/a
Nah, I only have on object to remove 5 handlers from it
Maybe when there will be more

--
Cheers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

"Peter Huang" <v-******@online.microsoft.com> wrote in message
news:zJ**************@cpmsftngxa07.phx.gbl...
Hi Critus,

So far, I think you may try Codemonkey's suggestions in his original post.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 20 '05 #18

P: n/a
Ok,

I've decided to channel my monkey-rambling energy into providing a
(hopefully) useful article on CodeProject about serialization of VB classes
with events.

Have a look at http://www.codeproject.com/useritems...evbclasses.asp

and let me know what you think

Best Regards,

Trev.

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:Oe**************@TK2MSFTNGP12.phx.gbl...
Heya All,

Sorry, but I think it's about time for a monkey-ramble.

I've just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the <Serialized()> attribute on the class and away you go. As Homer would say - "D'Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can't apply the <NonSerialized> attribute to the little rascals.
The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right
along with ObjectA.

If you don't believe me, go ahead and try it. Create a serializable class
with an event and some private fields. Create a form an declare an instance of the class and handle the event (with withevents or addhandler - doesn't
matter). Now try and serialize the instance of the class - you'll get a
serialization exception because the form (not the class you're trying to
serialize) isn't serializable!

Fair enough, you may say. This shouldn't be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can't
even do it reliably (because I have no way of telling who has attached to my events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of objects (say Trigger objects that fire an event periodically). The Collection of
triggers has it's own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a trigger's event when adding it to the collection. Now, guess what happens when you try and serialize the collection - it works! WooHoo!. Now try and deserialize
it. Again "D'Oh". This time you get an exception because you can't
deserialize a delegate to a private method for security reasons!

In my travels I've had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and their pros and cons:

1) Implement ISerializable and don't serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don't allow you to specify surrogates, so you end up re-writing
them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It's a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I'm mighty fed up with events. I realize that the fact that the <NonSerialized> attribute can't be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I'm off to learn C# ;)

Cheers,

Trev.

Nov 20 '05 #19

P: n/a
Trev,
I'm not so sure that the NonSerialized attribute needs to be fixed as much
as VB.NET needs to support the Field modifier on attributes. Other wise it
looks like a good article...

In C# you use:
[field: NonSerialized]
public event EventHandler NameChanged;
Unfortunately VB.NET only supports Assembly & Module modifiers on attributes

Such as:
<Assembly: NonSerialized>
or
<Module: NonSerialized>

The Field modifier is not supported.

<Field: NonSerialized> causes a syntax error.

Remember the thread from last October?

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:Oq****************@TK2MSFTNGP11.phx.gbl... Ok,

I've decided to channel my monkey-rambling energy into providing a
(hopefully) useful article on CodeProject about serialization of VB classes with events.

Have a look at http://www.codeproject.com/useritems...evbclasses.asp

and let me know what you think

Best Regards,

Trev.

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:Oe**************@TK2MSFTNGP12.phx.gbl...
Heya All,

Sorry, but I think it's about time for a monkey-ramble.

I've just had enough of trying to serialize even simple objects with VB. A simple task you may think - stick the <Serialized()> attribute on the class
and away you go. As Homer would say - "D'Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can't apply the <NonSerialized> attribute to the little rascals. The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right along with ObjectA.

If you don't believe me, go ahead and try it. Create a serializable class with an event and some private fields. Create a form an declare an

instance
of the class and handle the event (with withevents or addhandler - doesn't matter). Now try and serialize the instance of the class - you'll get a
serialization exception because the form (not the class you're trying to
serialize) isn't serializable!

Fair enough, you may say. This shouldn't be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can't
even do it reliably (because I have no way of telling who has attached to my
events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of

objects
(say Trigger objects that fire an event periodically). The Collection of
triggers has it's own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a

trigger's
event when adding it to the collection. Now, guess what happens when you

try
and serialize the collection - it works! WooHoo!. Now try and

deserialize it. Again "D'Oh". This time you get an exception because you can't
deserialize a delegate to a private method for security reasons!

In my travels I've had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and

their
pros and cons:

1) Implement ISerializable and don't serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don't allow you to specify surrogates, so you end up re-writing them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It's a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I'm mighty fed up with events. I realize that the fact

that
the <NonSerialized> attribute can't be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I'm off to learn C# ;)

Cheers,

Trev.


Nov 20 '05 #20

P: n/a
Good point. I'll see about modifying the article.

Cheers Jay.

Trev.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eM**************@TK2MSFTNGP11.phx.gbl...
Trev,
I'm not so sure that the NonSerialized attribute needs to be fixed as much
as VB.NET needs to support the Field modifier on attributes. Other wise it
looks like a good article...

In C# you use:
[field: NonSerialized]
public event EventHandler NameChanged;
Unfortunately VB.NET only supports Assembly & Module modifiers on

attributes
Such as:
<Assembly: NonSerialized>
or
<Module: NonSerialized>

The Field modifier is not supported.

<Field: NonSerialized> causes a syntax error.

Remember the thread from last October?

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:Oq****************@TK2MSFTNGP11.phx.gbl...
Ok,

I've decided to channel my monkey-rambling energy into providing a
(hopefully) useful article on CodeProject about serialization of VB classes
with events.

Have a look at http://www.codeproject.com/useritems...evbclasses.asp

and let me know what you think

Best Regards,

Trev.

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:Oe**************@TK2MSFTNGP12.phx.gbl...
Heya All,

Sorry, but I think it's about time for a monkey-ramble.

I've just had enough of trying to serialize even simple objects with VB. A simple task you may think - stick the <Serialized()> attribute on the

class
and away you go. As Homer would say - "D'Oh"

The root of my problem lies in the way VB implements Events and the
fact that you can't apply the <NonSerialized> attribute to the little rascals. The result of this is that when you serialize ObjectA that has an event EventX being handled by a method in ObjectB, ObjectB gets serialized right along with ObjectA.

If you don't believe me, go ahead and try it. Create a serializable class with an event and some private fields. Create a form an declare an

instance
of the class and handle the event (with withevents or addhandler - doesn't matter). Now try and serialize the instance of the class - you'll get a serialization exception because the form (not the class you're trying to serialize) isn't serializable!

Fair enough, you may say. This shouldn't be a big problem - just remove event handlers before serializing. Why should I have to do this? I can't even do it reliably (because I have no way of telling who has attached to
my
events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of

objects
(say Trigger objects that fire an event periodically). The Collection of triggers has it's own event which is raised when any of the triggers it contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a

trigger's
event when adding it to the collection. Now, guess what happens when you try
and serialize the collection - it works! WooHoo!. Now try and

deserialize it. Again "D'Oh". This time you get an exception because you can't
deserialize a delegate to a private method for security reasons!

In my travels I've had many suggestions about how to get around this
and have come up with some solutions on my own. Here are a few of them and

their
pros and cons:

1) Implement ISerializable and don't serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don't allow you to specify surrogates, so you end up

re-writing them too.

3) Implement ISerializable in a base class and use reflection to get all private fields in derived classes
Pros: It works
Cons: It's a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I'm mighty fed up with events. I realize that the fact

that
the <NonSerialized> attribute can't be applied to events is probably an oversight and will probably be fixed in the next version. Saying that, can anybody think of a valid reason why you would want to serialize an event (and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I'm off to learn C# ;)

Cheers,

Trev.



Nov 20 '05 #21

P: n/a
Looks like Codeproject edited and moved the article. It now resides at

http://www.codeproject.com/vb/net/se...evbclasses.asp

if you're interested.

Trev.
Nov 20 '05 #22

P: n/a
Trev,
Another couple of comments on your article.

<blockquote>
Because of the way VB.NET implements events, when you serialize an object,
its events get serialized too (because events are actually kinda like hidden
multicast delegate fields). A side effect of this is that any object which
handles events raised by the object being serialized will be considered part
of the object graph and will be serialized too.
</blockquote>

Events *are* implemented with hidden multicast delegate fields! (no kinda
about it)

Look at the following class with ILDASM.

Public Class EventClass

Public Event AnEvent As EventHandler

Public Sub Test()
If AnEventEvent Is Nothing Then
Debug.WriteLine("no", "Any handlers?")
Else
Debug.WriteLine("yes", "Any handlers?")
Debug.WriteLine(AnEventEvent.GetInvocationList().L ength, "#
handlers")
End If
End Sub

End Class

You should notice the event itself as 'AnEvent',

.event [mscorlib]System.EventHandler AnEvent

However you should also notice two routines add_AnEvent & remove_AnEvent,
these are used by the AddHandler & RemoveHandler statements,

.method public specialname instance void
add_AnEvent(class [mscorlib]System.EventHandler obj) cil managed
synchronized
.method public specialname instance void
remove_AnEvent(class [mscorlib]System.EventHandler obj) cil managed
synchronized

Plus you should notice the delegate field itself.

.field private class [mscorlib]System.EventHandler AnEventEvent

Which allows you within your code to use all the methods on Delegate to
manipulate the delegate. One I find useful is GetInvocationList to see how
many handlers are attached. Or checking to see if AnEventEvent is Nothing to
see if there is a Handler attached.

<blockquote>
The root of the problem is the fact that you cannot apply the
<NonSerialized> attribute to events or fields in VB
</blockquote>
You and I both know that "fields" above is referring to the underlying field
of the event, I'm not sure if you need qualify it with something like
"events or their fields"?

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Looks like Codeproject edited and moved the article. It now resides at

http://www.codeproject.com/vb/net/se...evbclasses.asp

if you're interested.

Trev.

Nov 20 '05 #23

P: n/a
Thanks for your help with this Jay. I'll fix up the article soon, taking
your recommendations into account.
Debug.WriteLine(AnEventEvent.GetInvocationList().L ength, "# handlers")
Nice one. I didn't know you could access an event delegate field in this way
(because it doesn't show up with intellisense). I guess it's just yet
another thing that VB tries its best to hide from the developer. IMHO, when
Microsoft brought things into the light that were hidden in VB6 (e.g. the
code behind the layout of a windows form), they should have went the whole
way. If they trust us with things like delegates, why go to such lengths to
hide the implementation of events?

Cheers again,

Trev.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:OO**************@TK2MSFTNGP10.phx.gbl... Trev,
Another couple of comments on your article.

<blockquote>
Because of the way VB.NET implements events, when you serialize an object,
its events get serialized too (because events are actually kinda like hidden multicast delegate fields). A side effect of this is that any object which
handles events raised by the object being serialized will be considered part of the object graph and will be serialized too.
</blockquote>

Events *are* implemented with hidden multicast delegate fields! (no kinda
about it)

Look at the following class with ILDASM.

Public Class EventClass

Public Event AnEvent As EventHandler

Public Sub Test()
If AnEventEvent Is Nothing Then
Debug.WriteLine("no", "Any handlers?")
Else
Debug.WriteLine("yes", "Any handlers?")
Debug.WriteLine(AnEventEvent.GetInvocationList().L ength, "# handlers")
End If
End Sub

End Class

You should notice the event itself as 'AnEvent',

.event [mscorlib]System.EventHandler AnEvent

However you should also notice two routines add_AnEvent & remove_AnEvent,
these are used by the AddHandler & RemoveHandler statements,

.method public specialname instance void
add_AnEvent(class [mscorlib]System.EventHandler obj) cil managed
synchronized
.method public specialname instance void
remove_AnEvent(class [mscorlib]System.EventHandler obj) cil managed synchronized

Plus you should notice the delegate field itself.

.field private class [mscorlib]System.EventHandler AnEventEvent

Which allows you within your code to use all the methods on Delegate to
manipulate the delegate. One I find useful is GetInvocationList to see how
many handlers are attached. Or checking to see if AnEventEvent is Nothing to see if there is a Handler attached.

<blockquote>
The root of the problem is the fact that you cannot apply the
<NonSerialized> attribute to events or fields in VB
</blockquote>
You and I both know that "fields" above is referring to the underlying field of the event, I'm not sure if you need qualify it with something like
"events or their fields"?

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Looks like Codeproject edited and moved the article. It now resides at

http://www.codeproject.com/vb/net/se...evbclasses.asp

if you're interested.

Trev.


Nov 20 '05 #24

P: n/a
Trev,
way. If they trust us with things like delegates, why go to such lengths to hide the implementation of events? To protected us from ourselves? ;-)

I think part of the "problem" is you have "most" VB.NET developers who is
Microsoft's "target" audience where the bulk of these details should be
hidden, hence the "Hide advanced members" option in VS.NET (Tools -
Options - Text Editor - Basic - General). As they don't "care" as they just
want to get their GUI done in a RAD fashion. (I'm not sure if I needed my
flame retardant suit on for that one or not ;-))

Then you have the significantly to extremely more advanced VB.NET developers
like you & I...

I'm sure when MS adds features they try to weigh the usefulness of
implementing it & the usefulness exposing it considering their target
audience... At least I hope they would as I know I would. ;-)

Its like an articles I was reading (a Chat I believe). VB.NET Whidbey may
get some Refactoring like features, however they may not call it Refactoring
(like C# Whidbey does) as their target audience may overlook a feature
called Refactoring, as they don't know what it is. Hell I mention
Refactoring in this newsgroup multiple times a month! ;-)

BTW: Refactoring = http://www.refactoring.com

Just a thought
Jay
"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:uw**************@TK2MSFTNGP10.phx.gbl... Thanks for your help with this Jay. I'll fix up the article soon, taking
your recommendations into account.
Debug.WriteLine(AnEventEvent.GetInvocationList().L ength, "# handlers")
Nice one. I didn't know you could access an event delegate field in this

way (because it doesn't show up with intellisense). I guess it's just yet
another thing that VB tries its best to hide from the developer. IMHO, when Microsoft brought things into the light that were hidden in VB6 (e.g. the
code behind the layout of a windows form), they should have went the whole
way. If they trust us with things like delegates, why go to such lengths to hide the implementation of events?

Cheers again,

Trev.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:OO**************@TK2MSFTNGP10.phx.gbl...
Trev,
Another couple of comments on your article.

<blockquote>
Because of the way VB.NET implements events, when you serialize an object, its events get serialized too (because events are actually kinda like hidden
multicast delegate fields). A side effect of this is that any object which handles events raised by the object being serialized will be considered

part
of the object graph and will be serialized too.
</blockquote>

Events *are* implemented with hidden multicast delegate fields! (no kinda about it)

Look at the following class with ILDASM.

Public Class EventClass

Public Event AnEvent As EventHandler

Public Sub Test()
If AnEventEvent Is Nothing Then
Debug.WriteLine("no", "Any handlers?")
Else
Debug.WriteLine("yes", "Any handlers?")
Debug.WriteLine(AnEventEvent.GetInvocationList().L ength,

"#
handlers")
End If
End Sub

End Class

You should notice the event itself as 'AnEvent',

.event [mscorlib]System.EventHandler AnEvent

However you should also notice two routines add_AnEvent & remove_AnEvent, these are used by the AddHandler & RemoveHandler statements,

.method public specialname instance void
add_AnEvent(class [mscorlib]System.EventHandler obj) cil managed
synchronized
.method public specialname instance void
remove_AnEvent(class [mscorlib]System.EventHandler obj) cil

managed
synchronized

Plus you should notice the delegate field itself.

.field private class [mscorlib]System.EventHandler AnEventEvent

Which allows you within your code to use all the methods on Delegate to
manipulate the delegate. One I find useful is GetInvocationList to see how many handlers are attached. Or checking to see if AnEventEvent is

Nothing to
see if there is a Handler attached.

<blockquote>
The root of the problem is the fact that you cannot apply the
<NonSerialized> attribute to events or fields in VB
</blockquote>
You and I both know that "fields" above is referring to the underlying

field
of the event, I'm not sure if you need qualify it with something like
"events or their fields"?

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Looks like Codeproject edited and moved the article. It now resides at

http://www.codeproject.com/vb/net/se...evbclasses.asp

if you're interested.

Trev.



Nov 20 '05 #25

P: n/a
> (I'm not sure if I needed my flame
retardant suit on for that one or not ;-))
Lol !
I'm sure when MS adds features they try to
weigh the usefulness of
implementing it & the usefulness
exposing it considering their target
audience... At least I hope they would as
I know I would. ;-)
I don't propose that I know anything about how the IDE is implemented, but I
would have thought that hiding the event field is a feature they would have
had to explicitly put into Visual Studio, not vise versa. As a side note on
weighing up the usefulness of something, I guess they missed the boat when
it came to those damn animated help assistants in Office and the like ;)

I totally agree with you on the target audience stuff (I've been known to
write applications for users that have trouble typing in numbers when the
numlock key gets un-selected ;), but at the same time, I think with the
power that .net brings to the world of VB (e.g. threading, remoting etc.
etc.) it's time that Microsoft considered that there may a good few more
"advanced" users out there (not that there was any shortage under VB6).
Didn't I hear somewhere that "all .net languages were created equal"? Guess
it's just a case of "some are more equal than others" ;)
Hell I mention
Refactoring in this
newsgroup multiple times a month! ;-)
*gets dictionary out, looks up link, saves in favourites for a closer look*

Seriously, I'll have to take a look at that soon. For those (like me) who
didn't know what refactoring is:

http://www.google.com/search?q=define%3A+Refactoring
Cheers again for your thoughts,

Trev.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... Trev,
way. If they trust us with things like delegates, why go to such lengths to
hide the implementation of events?

To protected us from ourselves? ;-)

I think part of the "problem" is you have "most" VB.NET developers who is
Microsoft's "target" audience where the bulk of these details should be
hidden, hence the "Hide advanced members" option in VS.NET (Tools -
Options - Text Editor - Basic - General). As they don't "care" as they

just want to get their GUI done in a RAD fashion. (I'm not sure if I needed my
flame retardant suit on for that one or not ;-))

Then you have the significantly to extremely more advanced VB.NET developers like you & I...

I'm sure when MS adds features they try to weigh the usefulness of
implementing it & the usefulness exposing it considering their target
audience... At least I hope they would as I know I would. ;-)

Its like an articles I was reading (a Chat I believe). VB.NET Whidbey may
get some Refactoring like features, however they may not call it Refactoring (like C# Whidbey does) as their target audience may overlook a feature
called Refactoring, as they don't know what it is. Hell I mention
Refactoring in this newsgroup multiple times a month! ;-)

BTW: Refactoring = http://www.refactoring.com

Just a thought
Jay
"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:uw**************@TK2MSFTNGP10.phx.gbl...
Thanks for your help with this Jay. I'll fix up the article soon, taking
your recommendations into account.
Debug.WriteLine(AnEventEvent.GetInvocationList().L ength, "# handlers")


Nice one. I didn't know you could access an event delegate field in this

way
(because it doesn't show up with intellisense). I guess it's just yet
another thing that VB tries its best to hide from the developer. IMHO,

when
Microsoft brought things into the light that were hidden in VB6 (e.g. the
code behind the layout of a windows form), they should have went the whole way. If they trust us with things like delegates, why go to such lengths

to
hide the implementation of events?

Cheers again,

Trev.

"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message news:OO**************@TK2MSFTNGP10.phx.gbl...
Trev,
Another couple of comments on your article.

<blockquote>
Because of the way VB.NET implements events, when you serialize an object, its events get serialized too (because events are actually kinda like

hidden
multicast delegate fields). A side effect of this is that any object which handles events raised by the object being serialized will be considered part
of the object graph and will be serialized too.
</blockquote>

Events *are* implemented with hidden multicast delegate fields! (no kinda about it)

Look at the following class with ILDASM.

Public Class EventClass

Public Event AnEvent As EventHandler

Public Sub Test()
If AnEventEvent Is Nothing Then
Debug.WriteLine("no", "Any handlers?")
Else
Debug.WriteLine("yes", "Any handlers?")
Debug.WriteLine(AnEventEvent.GetInvocationList().L ength,
"#
handlers")
End If
End Sub

End Class

You should notice the event itself as 'AnEvent',

.event [mscorlib]System.EventHandler AnEvent

However you should also notice two routines add_AnEvent &

remove_AnEvent, these are used by the AddHandler & RemoveHandler statements,

.method public specialname instance void
add_AnEvent(class [mscorlib]System.EventHandler obj) cil
managed synchronized
.method public specialname instance void
remove_AnEvent(class [mscorlib]System.EventHandler obj) cil

managed
synchronized

Plus you should notice the delegate field itself.

.field private class [mscorlib]System.EventHandler AnEventEvent

Which allows you within your code to use all the methods on Delegate to manipulate the delegate. One I find useful is GetInvocationList to see

how many handlers are attached. Or checking to see if AnEventEvent is

Nothing
to
see if there is a Handler attached.

<blockquote>
The root of the problem is the fact that you cannot apply the
<NonSerialized> attribute to events or fields in VB
</blockquote>
You and I both know that "fields" above is referring to the underlying

field
of the event, I'm not sure if you need qualify it with something like
"events or their fields"?

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
> Looks like Codeproject edited and moved the article. It now resides at >
> http://www.codeproject.com/vb/net/se...evbclasses.asp
>
> if you're interested.
>
> Trev.
>
>



Nov 20 '05 #26

P: n/a
Trev,
I don't propose that I know anything about how the IDE is implemented, but I would have thought that hiding the event field is a feature they would have had to explicitly put into Visual Studio, not vise versa I view the hiding the Event an artifact of how VB.NET is implemented on top
of IL & the CLR, not so much how VB.NET is integrated with VS.NET. Which is
why they are "hidden" even from the "hide advanced members".
Didn't I hear somewhere that "all .net languages were created equal"? Guess it's just a case of "some are more equal than others" ;) IMHO they are "created equal" by virtue they are all built on top of IL &
the CLR, however they are not equal, as how each language exposes an IL/CLR
feature may be different, if they expose it.

For example C# supports defining the add/remove procedures for Events
(similar to the get/set for properties) while VB.NET handles (no pun
intended) it completely for you. Or that VB.NET supports the WithEvents &
Handles keyword (which causes the WithEvents field to really be an IL
property) while C# requires you to code that logic yourself...

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:eD**************@TK2MSFTNGP11.phx.gbl...
(I'm not sure if I needed my flame
retardant suit on for that one or not ;-))


Lol !
I'm sure when MS adds features they try to
weigh the usefulness of
implementing it & the usefulness
exposing it considering their target
audience... At least I hope they would as
I know I would. ;-)


I don't propose that I know anything about how the IDE is implemented, but

I would have thought that hiding the event field is a feature they would have had to explicitly put into Visual Studio, not vise versa. As a side note on weighing up the usefulness of something, I guess they missed the boat when
it came to those damn animated help assistants in Office and the like ;)

I totally agree with you on the target audience stuff (I've been known to
write applications for users that have trouble typing in numbers when the
numlock key gets un-selected ;), but at the same time, I think with the
power that .net brings to the world of VB (e.g. threading, remoting etc.
etc.) it's time that Microsoft considered that there may a good few more
"advanced" users out there (not that there was any shortage under VB6).
Didn't I hear somewhere that "all .net languages were created equal"? Guess it's just a case of "some are more equal than others" ;)
Hell I mention
Refactoring in this
newsgroup multiple times a month! ;-)
*gets dictionary out, looks up link, saves in favourites for a closer

look*
Seriously, I'll have to take a look at that soon. For those (like me) who
didn't know what refactoring is:

http://www.google.com/search?q=define%3A+Refactoring
Cheers again for your thoughts,

Trev.

<<snip>>
Nov 20 '05 #27

P: n/a
> I view the hiding the Event an artifact
of how VB.NET is implemented on top
of IL & the CLR, not so much how VB.NET
is integrated with VS.NET. Which is
why they are "hidden" even from the
"hide advanced members".
I see where you're coming from, but IMLB the hiding of the event delegate
field would be done somewhere in the IDE - it is visible in IL, and even
appears with intellisense once you type the name for yourself (could this be
one of those "back-doors" left over from development and testing of the
ide?)

No big deal anyway. Just rolling things over in my head. Many thanks again
for all your help. I should have a new and improved version of the article
(and source code) by the end of the week if you're still interested.

Thanks again,

Trev.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:OC*************@TK2MSFTNGP11.phx.gbl... Trev,
I don't propose that I know anything about how the IDE is implemented, but
I
would have thought that hiding the event field is a feature they would have
had to explicitly put into Visual Studio, not vise versa

I view the hiding the Event an artifact of how VB.NET is implemented on

top of IL & the CLR, not so much how VB.NET is integrated with VS.NET. Which is why they are "hidden" even from the "hide advanced members".
Didn't I hear somewhere that "all .net languages were created equal"? Guess
it's just a case of "some are more equal than others" ;)

IMHO they are "created equal" by virtue they are all built on top of IL &
the CLR, however they are not equal, as how each language exposes an

IL/CLR feature may be different, if they expose it.

For example C# supports defining the add/remove procedures for Events
(similar to the get/set for properties) while VB.NET handles (no pun
intended) it completely for you. Or that VB.NET supports the WithEvents &
Handles keyword (which causes the WithEvents field to really be an IL
property) while C# requires you to code that logic yourself...

Hope this helps
Jay

"Trev Hunter" <hu*********@hotmail.com> wrote in message
news:eD**************@TK2MSFTNGP11.phx.gbl... (I'm not sure if I needed my flame
retardant suit on for that one or not ;-))
Lol !
I'm sure when MS adds features they try to
weigh the usefulness of
implementing it & the usefulness
exposing it considering their target
audience... At least I hope they would as
I know I would. ;-)


I don't propose that I know anything about how the IDE is implemented, but I
would have thought that hiding the event field is a feature they would

have
had to explicitly put into Visual Studio, not vise versa. As a side note

on
weighing up the usefulness of something, I guess they missed the boat

when it came to those damn animated help assistants in Office and the like ;)

I totally agree with you on the target audience stuff (I've been known to write applications for users that have trouble typing in numbers when the numlock key gets un-selected ;), but at the same time, I think with the
power that .net brings to the world of VB (e.g. threading, remoting etc.
etc.) it's time that Microsoft considered that there may a good few more
"advanced" users out there (not that there was any shortage under VB6).
Didn't I hear somewhere that "all .net languages were created equal"?

Guess
it's just a case of "some are more equal than others" ;)
Hell I mention
Refactoring in this
newsgroup multiple times a month! ;-)


*gets dictionary out, looks up link, saves in favourites for a closer

look*

Seriously, I'll have to take a look at that soon. For those (like me) who didn't know what refactoring is:

http://www.google.com/search?q=define%3A+Refactoring
Cheers again for your thoughts,

Trev.

<<snip>>

Nov 20 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.