views:

434

answers:

3

This question is close to what I'm interested in, but not quite.

I have a .NET WinForms application written in C#. I have a ListView control which displays an array of C# objects. I've hooked it up so that you can drag/drop these listview items to a different form in the same application, and it properly passes the array of objects (type "Session") to the Drop handler for that other form.

However, I now want to support cross-process drag/drop where I run multiple instances of my application. This appears that it's going to work (e.g. GetDataPresent succeeds), but ultimately throws an exception when I actually try to retrieve the data-- cannot cast object[] to Session[].

if (e.Data.GetDataPresent("Fiddler.Session[]"))
{
   Session[] oDroppedSessions;
   try
   {
      oDroppedSessions = (Session[])e.Data.GetData("Fiddler.Session[]");
   }
   catch (Exception eX)
   {  // reaches here 
   }
}

Anyone know if I must implement ISerializable for my objects in order to make this work? Ordinarily, I'd simply try it, but implementing ISerializable for this class would be quite non-trivial, and I'm worried that there may be weird side-effects of doing so.


UPDATE: Implementing ISerializable doesn't help-- the method is never called. Similarly, adding the Serializable attribute to the class has no impact at all. Any other ideas?

thanks for any pointers!

A: 

You could use "as" for casting which will avoid the exception ("as" will return "null" without throwing an exception if the cast fails) - but I don't think this will solve your problem (it will just avoid the actual exception), as I agree it's likely you'll have to make your class Serializable. You could test your hypothesis by commenting out the fields that will be harder to make it work - just for now to test it.

Andy Jacobs
-1: Trading an `InvalidCastException` for a `NullReferenceException` is a loss of information. The `as` keyword is good if you expect that a cast *might* fail. Otherwise, it's bad, and I've seen it overused a lot.
P Daddy
A: 
tommieb75
+1  A: 

You are crossing a process boundary, object references are not valid in another process. The DataObject class supports serializing objects to get them across the wall, it uses BinaryFormatter. So, yes, you'll need to apply the [Serializable] attribute to your class and make sure your objects can de/serialize properly.

Hans Passant
Yeah, that's what I was afraid of. Any idea if I'm going to introduce performance regressions if I implement ISerializable? The binary serialization of this object might be hundreds of KB.
EricLaw -MSFT-
Let us know when you find out please.
Hans Passant
Hmmm... implementing ISerializable doesn't help-- the method is never called. Similarly, adding the Serializable attribute to the class has no impact at all. Any other ideas?
EricLaw -MSFT-
Use DataFormat.Serializable to trigger the serialization code.
Hans Passant
It turns out that if I add both ISerializable AND the Serializable attribute, and put a MessageBox in the ISerializable implementation, *then* I see it get hit. If I simply let my ISerializable implementation emit a Not Yet Implemented exception, that exception gets eaten somewhere along the way and I still get the old "cannot convert object[] to Session[]" exception.So, now I've just got to write a bunch of code to make my ISerializable implementation work.Thanks for your help!
EricLaw -MSFT-