Hi all. I'm trying to do what I thought was a cut and clear serialization of a settings class into a .dat file. I am receiving the SerailizeException because a form in my class library is not marked as serializable. The problem is that I cannot see any place where I am referencing a member of my form (frmMain). In fact, when I make frmMain serializable with teh attribute it then gives another exception that class Form itself is not marked as serializable -- which I'm reasonably sure it is not but of course I have no control over that.

Some background on the project: It is essentiallya library that allows the user to select Excel workbooks and choose certain settings related to the workbook (ie. HasHeader, data start cell address, etc.) The form itself which allows the user to choose the workbooks, worksheets and setting values is not directly exposed -- it is called from witin the only exposed class that can be instantiated (the WorkbookManager class). So many of the values in the form's controls are exposed by proxy through the manager's properties.

There are many helper classes and structures but none of them belong to the frmMain class. The settings themselves are serialized in a module method and is called from outside the form -- in the manager class. I do have a listbox on the form that is bound to a generic list of a custom class -- could having pointers to the objects from a listbox interfere with serialization? The Settings object itself that is serialized is just a List (Of WorkbookInfo). Oh, and all the custom classes and structures used in teh dependency hierarchy are marked as serializable -- I double checked and could not find any reference to the frmMain instance anywhere in them.

So my question: Is there something inherent in using a form within a class library that forces that form to be included in the serialization of a module-level object?

Thanks in advance.

-DB

Have found a solution to this? Are you able to create instances of the object without creating instances of the form and serialize successfully? Is there any refactoring you can do to make sure the data class is distinct from the form?

Thanks.

I've done a little more probing on the issue and came up with some interesting results. First I copied and pasted the entire module with the serializable classes into a new Windows Forms app with simple buttons to test the saving and loading to/from the .dat file. That worked fine (I kind of did this before with the same results but forgot to mention it in the OP - sorry). I tried to include all the class-level references to these classes that are in the original library including events that are consumed. Everything worked fine.

So then I compiled that app (single form with buttons and the classes) and created a new Windows Forms app in which I added a refernce to this newly created testing library. It worked fine (I thought it would not so the mystery deepened). At this point I thought maybe it was a fluke so I re-added the save and load (serialization)feature to the original class library and called it from my little test app... and it worked this time!! Feeling good about this I tried it alittle further and started actualy using the UI in the orginal library -- the stuff that interracts with the objects being serialized -- and then the error came back! Here's the error message..

Type 'MRF.frmMain' in Assembly 'WorkbookManager, Version 1.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable

So my take away from thiswas that something in how the form's UI latches on to the class objects is placing itself into the serialization queue. It just doesn't seem right to me but to test it I moved any class instance variables that reference the objects that are being serialized (i.e. "CurrentWorkbookInfo" which represents the currently selected one that the UI is manipulating but which also resides within the generic List object that eventually gets serialized).

The good news is that it solved the issue!! Everything works correctly now. The only problem is that I have to reorganize my form as a proxy object because it was passign on events being raised by the objects -- but you cannot apparently handle events of objects that are defined at a module level or not within the class itself. I'm sure I'll find the workaround soon.


So my question remains I guess -- How does having a reference to an object both within a form (as an instance variable) and within a module-level collection that is marked for serialization create a situation where the form becomes part of the serialization? Does this mean that any class you want to have serialized cannot have an instance of it declared within a form (at least at a class-level)? That sounds rather restrictive and illogical.

Have found a solution to this? Are you able to create instances of the object without creating instances of the form and serialize successfully? Is there any refactoring you can do to make sure the data class is distinct from the form?

Thanks.

I'm sorry Nathan -- I've been having big problems with getting alerts from the forums to my email and this thread slipped by. I have not found a solution and I needed to stop development on that aspect of the library temporarily as I needed to work on some other more pressing projects. I will try to pick it up again soon and re-post any progress. Thank you for showing an interest -- this is not my strong point and I could use some knowledgable assistance. Though this approach may not be necessary for the library I would like to understand what is going wrong so I can learn for the nest time it comes up.

I've done a little more probing on the issue and came up with some interesting results. First I copied and pasted the entire module with the serializable classes into a new Windows Forms app with simple buttons to test the saving and loading to/from the .dat file. That worked fine (I kind of did this before with the same results but forgot to mention it in the OP - sorry). I tried to include all the class-level references to these classes that are in the original library including events that are consumed. Everything worked fine.

So then I compiled that app (single form with buttons and the classes) and created a new Windows Forms app in which I added a refernce to this newly created testing library. It worked fine (I thought it would not so the mystery deepened). At this point I thought maybe it was a fluke so I re-added the save and load (serialization)feature to the original class library and called it from my little test app... and it worked this time!! Feeling good about this I tried it alittle further and started actualy using the UI in the orginal library -- the stuff that interracts with the objects being serialized -- and then the error came back! Here's the error message..

Type 'MRF.frmMain' in Assembly 'WorkbookManager, Version 1.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable

So my take away from thiswas that something in how the form's UI latches on to the class objects is placing itself into the serialization queue. It just doesn't seem right to me but to test it I moved any class instance variables that reference the objects that are being serialized (i.e. "CurrentWorkbookInfo" which represents the currently selected one that the UI is manipulating but which also resides within the generic List object that eventually gets serialized).

The good news is that it solved the issue!! Everything works correctly now. The only problem is that I have to reorganize my form as a proxy object because it was passign on events being raised by the objects -- but you cannot apparently handle events of objects that are defined at a module level or not within the class itself. I'm sure I'll find the workaround soon.


So my question remains I guess -- How does having a reference to an object both within a form (as an instance variable) and within a module-level collection that is marked for serialization create a situation where the form becomes part of the serialization? Does this mean that any class you want to have serialized cannot have an instance of it declared within a form (at least at a class-level)? That sounds rather restrictive and illogical.

Short Answer:

[field: NonSerialized]
public event .... ....;


Long Answer:
http://www.artima.com/forums/flat.jsp?forum=152&thread=247048