Hooking events post deserialisation

[nick.fletcher]

I have a custom collection which derives from Collection<which stores
a number of objects. Before each item is added to the collection - an
event which it exposes is hooked by the collection and the re-fired to
its parent.

eg

class MyCollection : Collection<MyType>
{
public AddAnObject(MyType obj)
{
obj.SomeEvent += new eventhandler(obj_somethingChanged);
base.Add(obj);
}

private void obj_somethingChanged(object sender, EventArgs e)
{
Do something.....
}
}

The problem I have is that if you serialise and then deserialise the
collection, the events are no longer connected. You could probably fix
this in the deserialisation constructor but Im using CF and this doesnt
support System.Runtime.Serialisation. I can fix it by manually going
through the collection after it has been created and re-connecting but
does anyone know a better way?

[Wiebe Tijsma]

Hi Nick,

I'm afraid you will have to reattach the events:

Implementing IDeserializationCallback on your collection will allow you
to get a callback as soon as deserialization is complete.

Regards,

Wiebe Tijsma
http://www.e-office.com

Hi,ni***********@iinet.net.au wrote:

I have a custom collection which derives from Collection<which stores
a number of objects. Before each item is added to the collection - an
event which it exposes is hooked by the collection and the re-fired to
its parent.

eg

class MyCollection : Collection<MyType>
{
public AddAnObject(MyType obj)
{
obj.SomeEvent += new eventhandler(obj_somethingChanged);
base.Add(obj);
}

private void obj_somethingChanged(object sender, EventArgs e)
{
Do something.....
}
}

The problem I have is that if you serialise and then deserialise the
collection, the events are no longer connected. You could probably fix
this in the deserialisation constructor but Im using CF and this doesnt
support System.Runtime.Serialisation. I can fix it by manually going
through the collection after it has been created and re-connecting but
does anyone know a better way?

[nick.fletcher]

I thought so much :-( Thanks for the hint on the interface though -
I'll give that a shot

On Nov 24, 10:14 pm, Wiebe Tijsma <[e-mail]>
wrote:

Hi Nick,

I'm afraid you will have to reattach the events:

Implementing IDeserializationCallback on your collection will allow you
to get a callback as soon as deserialization is complete.

Regards,

Wiebe Tijsmahttp://www.e-office.com

Hi,[e-mail] wrote:

I have a custom collection which derives from Collection<which stores
a number of objects. Before each item is added to the collection - an
event which it exposes is hooked by the collection and the re-fired to
its parent.

eg

class MyCollection : Collection<MyType>
{
public AddAnObject(MyType obj)
{
obj.SomeEvent += new eventhandler(obj_somethingChanged);
base.Add(obj);
}

private void obj_somethingChanged(object sender, EventArgs e)
{
Do something.....
}
}

The problem I have is that if you serialise and then deserialise the
collection, the events are no longer connected. You could probably fix
this in the deserialisation constructor but Im using CF and this doesnt
support System.Runtime.Serialisation. I can fix it by manually going
through the collection after it has been created and re-connecting but
does anyone know a better way?

[Wiebe Tijsma]

Hi Nick,

You're welcome :)

If I may give an additional advise:

In my opinion, in most situations where events are used, they can be
replaced by a different architectural design using interfaces or
abstract base classes, especially on scenarios where serialization is
involved.

(events are evil :p)

Regards,

Wiebe Tijsma
ni***********@iinet.net.au wrote:

I thought so much :-( Thanks for the hint on the interface though -
I'll give that a shot

On Nov 24, 10:14 pm, Wiebe Tijsma <[e-mail]>
wrote:

>Hi Nick,

I'm afraid you will have to reattach the events:

Implementing IDeserializationCallback on your collection will allow you
to get a callback as soon as deserialization is complete.

Regards,

Wiebe Tijsmahttp://www.e-office.com

Hi,[e-mail] wrote:

>>I have a custom collection which derives from Collection<which stores
a number of objects. Before each item is added to the collection - an
event which it exposes is hooked by the collection and the re-fired to
its parent.
eg
class MyCollection : Collection<MyType>
{
public AddAnObject(MyType obj)
{
obj.SomeEvent += new eventhandler(obj_somethingChanged);
base.Add(obj);
}
private void obj_somethingChanged(object sender, EventArgs e)
{
Do something.....
}
}
The problem I have is that if you serialise and then deserialise the
collection, the events are no longer connected. You could probably fix
this in the deserialisation constructor but Im using CF and this doesnt
support System.Runtime.Serialisation. I can fix it by manually going
through the collection after it has been created and re-connecting but
does anyone know a better way?

[nick.fletcher]

Still no joy!

IDeserializationCallback is unfortunately a
System.Runtime.Serialization interface and is not supported under CF.
Wrt your last post - how could I change the architecture such that one
class can asynchronously notify another of an event via an
interface/abstract class. I mean, I could also use a delegate but I end
up with the same problem in that serialization will only serialize
public properties

Many thanks

Nick

On Nov 27, 3:29 am, Wiebe Tijsma <[e-mail]>
wrote:

Hi Nick,

You're welcome :)

If I may give an additional advise:

In my opinion, in most situations where events are used, they can be
replaced by a different architectural design using interfaces or
abstract base classes, especially on scenarios where serialization is
involved.

(events are evil :p)

Regards,

Wiebe Tijsma

[e-mail] wrote:

I thought so much :-( Thanks for the hint on the interface though -
I'll give that a shot

On Nov 24, 10:14 pm, Wiebe Tijsma <[e-mail]>
wrote:

Hi Nick,

I'm afraid you will have to reattach the events:

Implementing IDeserializationCallback on your collection will allow you
to get a callback as soon as deserialization is complete.

Regards,

Wiebe Tijsmahttp://www.e-office.com

Hi,[e-mail] wrote:
I have a custom collection which derives from Collection<which stores
a number of objects. Before each item is added to the collection - an
event which it exposes is hooked by the collection and the re-fired to
its parent.
eg
class MyCollection : Collection<MyType>
{
public AddAnObject(MyType obj)
{
obj.SomeEvent += new eventhandler(obj_somethingChanged);
base.Add(obj);
}
private void obj_somethingChanged(object sender, EventArgs e)
{
Do something.....
}
}
The problem I have is that if you serialise and then deserialise the
collection, the events are no longer connected. You could probably fix
this in the deserialisation constructor but Im using CF and this doesnt
support System.Runtime.Serialisation. I can fix it by manually going
through the collection after it has been created and re-connecting but
does anyone know a better way?

[Wiebe Tijsma]

Hi Nick,

I'm sorry for the wrong information then, I don't use the CF.

Are you using the XmlSerializer? this will only serialize public properties.

The binary serialization will serialize the in-memory representation of
your objects (fields), not the public properties.

What you could do is implement IEnumerable on your object model, and
iterate through your graph querying your object model for your own
custom interface that requires the callback (IMyCallBack) and execute
that recursively as soon as deserialization is complete.

In that case you can also reattach your events.

Best regards,

Wiebe Tijsma
http://www.e-office.com
ni***********@iinet.net.au wrote:

Still no joy!

IDeserializationCallback is unfortunately a
System.Runtime.Serialization interface and is not supported under CF.
Wrt your last post - how could I change the architecture such that one
class can asynchronously notify another of an event via an
interface/abstract class. I mean, I could also use a delegate but I end
up with the same problem in that serialization will only serialize
public properties

Many thanks

Nick

On Nov 27, 3:29 am, Wiebe Tijsma <[e-mail]>
wrote:

>Hi Nick,

You're welcome :)

If I may give an additional advise:

In my opinion, in most situations where events are used, they can be
replaced by a different architectural design using interfaces or
abstract base classes, especially on scenarios where serialization is
involved.

(events are evil :p)

Regards,

Wiebe Tijsma

[e-mail] wrote:

>>I thought so much :-( Thanks for the hint on the interface though -
I'll give that a shot
On Nov 24, 10:14 pm, Wiebe Tijsma <[e-mail]>
wrote:
Hi Nick,
I'm afraid you will have to reattach the events:
Implementing IDeserializationCallback on your collection will allow you
to get a callback as soon as deserialization is complete.
Regards,
Wiebe Tijsmahttp://www.e-office.com
Hi,[e-mail] wrote:
I have a custom collection which derives from Collection<which stores
a number of objects. Before each item is added to the collection - an
event which it exposes is hooked by the collection and the re-fired to
its parent.
eg
class MyCollection : Collection<MyType>
{
public AddAnObject(MyType obj)
{
obj.SomeEvent += new eventhandler(obj_somethingChanged);
base.Add(obj);
}
private void obj_somethingChanged(object sender, EventArgs e)
{
Do something.....
}
}
The problem I have is that if you serialise and then deserialise the
collection, the events are no longer connected. You could probably fix
this in the deserialisation constructor but Im using CF and this doesnt
support System.Runtime.Serialisation. I can fix it by manually going
through the collection after it has been created and re-connecting but
does anyone know a better way?

[nick.fletcher]

Hiya

I actually found a solution

When the collection which holds the objects is deserialized it actually
calls it Add() method on the base class. All I needed to do was
override the add instead of wrapping it and hey presto

Thanks for your help though :-)

On Nov 28, 11:37 am, Wiebe Tijsma <[e-mail]>
wrote:

Hi Nick,

I'm sorry for the wrong information then, I don't use the CF.

Are you using the XmlSerializer? this will only serialize public properties.

The binary serialization will serialize the in-memory representation of
your objects (fields), not the public properties.

What you could do is implement IEnumerable on your object model, and
iterate through your graph querying your object model for your own
custom interface that requires the callback (IMyCallBack) and execute
that recursively as soon as deserialization is complete.

In that case you can also reattach your events.

Best regards,

Wiebe Tijsmahttp://www.e-office.com

[e-mail] wrote:

Still no joy!

IDeserializationCallback is unfortunately a
System.Runtime.Serialization interface and is not supported under CF.
Wrt your last post - how could I change the architecture such that one
class can asynchronously notify another of an event via an
interface/abstract class. I mean, I could also use a delegate but I end
up with the same problem in that serialization will only serialize
public properties

Many thanks

Nick

On Nov 27, 3:29 am, Wiebe Tijsma <[e-mail]>
wrote:

Hi Nick,

You're welcome :)

If I may give an additional advise:

In my opinion, in most situations where events are used, they can be
replaced by a different architectural design using interfaces or
abstract base classes, especially on scenarios where serialization is
involved.

(events are evil :p)

Regards,

Wiebe Tijsma

[e-mail] wrote:
I thought so much :-( Thanks for the hint on the interface though -
I'll give that a shot
On Nov 24, 10:14 pm, Wiebe Tijsma <[e-mail]>
wrote:
Hi Nick,
I'm afraid you will have to reattach the events:
Implementing IDeserializationCallback on your collection will allow you
to get a callback as soon as deserialization is complete.
Regards,
Wiebe Tijsmahttp://www.e-office.com
Hi,[e-mail] wrote:
I have a custom collection which derives from Collection<which stores
a number of objects. Before each item is added to the collection - an
event which it exposes is hooked by the collection and the re-fired to
its parent.
eg
class MyCollection : Collection<MyType>
{
public AddAnObject(MyType obj)
{
obj.SomeEvent += new eventhandler(obj_somethingChanged);
base.Add(obj);
}
private void obj_somethingChanged(object sender, EventArgs e)
{
Do something.....
}
}
The problem I have is that if you serialise and then deserialise the
collection, the events are no longer connected. You could probably fix
this in the deserialisation constructor but Im using CF and this doesnt
support System.Runtime.Serialisation. I can fix it by manually going
through the collection after it has been created and re-connecting but
does anyone know a better way?

[Wiebe Tijsma]

Ah, so are you using the XmlSerializer then?
ni***********@iinet.net.au wrote:

Hiya

I actually found a solution

When the collection which holds the objects is deserialized it actually
calls it Add() method on the base class. All I needed to do was
override the add instead of wrapping it and hey presto

Thanks for your help though :-)

On Nov 28, 11:37 am, Wiebe Tijsma <[e-mail]>
wrote:

>Hi Nick,

I'm sorry for the wrong information then, I don't use the CF.

Are you using the XmlSerializer? this will only serialize public properties.

The binary serialization will serialize the in-memory representation of
your objects (fields), not the public properties.

What you could do is implement IEnumerable on your object model, and
iterate through your graph querying your object model for your own
custom interface that requires the callback (IMyCallBack) and execute
that recursively as soon as deserialization is complete.

In that case you can also reattach your events.

Best regards,

Wiebe Tijsmahttp://www.e-office.com

[e-mail] wrote:

>>Still no joy!
IDeserializationCallback is unfortunately a
System.Runtime.Serialization interface and is not supported under CF.
Wrt your last post - how could I change the architecture such that one
class can asynchronously notify another of an event via an
interface/abstract class. I mean, I could also use a delegate but I end
up with the same problem in that serialization will only serialize
public properties
Many thanks
Nick
On Nov 27, 3:29 am, Wiebe Tijsma <[e-mail]>
wrote:
Hi Nick,
You're welcome :)
If I may give an additional advise:
In my opinion, in most situations where events are used, they can be
replaced by a different architectural design using interfaces or
abstract base classes, especially on scenarios where serialization is
involved.
(events are evil :p)
Regards,
Wiebe Tijsma
[e-mail] wrote:
I thought so much :-( Thanks for the hint on the interface though -
I'll give that a shot
On Nov 24, 10:14 pm, Wiebe Tijsma <[e-mail]>
wrote:
>Hi Nick,
>I'm afraid you will have to reattach the events:
>Implementing IDeserializationCallback on your collection will allow you
>to get a callback as soon as deserialization is complete.
>Regards,
>Wiebe Tijsmahttp://www.e-office.com
>Hi,[e-mail] wrote:
>>I have a custom collection which derives from Collection<which stores
>>a number of objects. Before each item is added to the collection - an
>>event which it exposes is hooked by the collection and the re-fired to
>>its parent.
>>eg
>>class MyCollection : Collection<MyType>
>>{
>> public AddAnObject(MyType obj)
>> {
>> obj.SomeEvent += new eventhandler(obj_somethingChanged);
>> base.Add(obj);
>> }
>> private void obj_somethingChanged(object sender, EventArgs e)
>> {
>> Do something.....
>> }
>>}
>>The problem I have is that if you serialise and then deserialise the
>>collection, the events are no longer connected. You could probably fix
>>this in the deserialisation constructor but Im using CF and this doesnt
>>support System.Runtime.Serialisation. I can fix it by manually going
>>through the collection after it has been created and re-connecting but
>>does anyone know a better way?