[the.jack]

Hello to dream.in.code community. I figured this would be a common question, but upon searching (here and Google) I can't seem to find an obvious solution to my issue.

The problem is, having converted from VS 2002 to VS 2008 the designer can't seem to handle the custom controls on "my" (not original designer) app. Any time I try to copy, in particular, the custom derived comboBox control I get this error initially:
Type 'Corporate.Controls.data.comboBox+comboBoxDataSource+Item' in Assembly Corporate.Controls, ... is not marked as serializable.

I chased this error down, marking classes Serializable and private variables therein as NonSerialized when they caused a problem (which might or might not be the smartest way to attack this problem...) but I've hit a brick wall. The most base corporate derived ComboBox class is:

Namespace Corporate.Controls
Public Class comboBox
	Inherits System.Windows.Forms.ComboBox
	
	...
End Class

It's unrealistic to post all of the relevant code (I believe). The short of it is:
System.Windows.Forms.ComboBox <- Corporate.Controls.comboBox <- Corporate.Controls.data.comboBox
I just kept backtracking through the errors.

At this point I can't set System.Windows.Forms.ComboBox to Serializable. I've tried marking the Inherits System.Windows.Forms.ComboBox clause with <NonSerialized()> and while that doesn't cause a build error it doesn't seem to fix the designer-generated error in the other libraries when I go to actually add, copy or even delete the control in WYSIWYG. And that is the only reference to System.Windows.Forms.ComboBox in that (or any other) corporate library.

So... I'm not sure what to do. I'm also not even really sure what this is "doing" for me, since there was nothing about Serialization in VS 2002 and these controls worked just fine there.

Thanks for any advice!
Chris C.

[the.jack]

After going back through sometimes the compiler does reject setting the Inherits System.Windows.Forms.ComboBox clause with NonSerialized... Which is odd, but it doesn't appear to have done anything. As I assumed it would error in the first place since it's not an instance statement, I'm not surprised.

[_HAWK_]

Controls are not serializable, unfortunately. I would just add a new class, add the inherits combobox and copy the code from the old one into here, then all should be well.

[the.jack]

hawkvalley1,

I didn't think so, which is what I found so frustrating... I just wanted VS to stop trying. I wanted a Project setting for Serialization valued "stop it".

But, I circuitously fixed the problem. I stopped trying to copy, delete or modify components already on-screen and added a fresh control to a restored copy of my particular test form. I'd already done this back when the error first came up, but it was one of those "haven't quite tried this permutation yet" type of things.

Once I did that the error was slightly different, complaining first about a specific property (rather than complaining about a class - much easier to alter!): the Shadowed ReadOnly (access change!) DataSource [Object]. So I set this to <DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)>. I no longer received Designer errors (hooray!) but now the auto-code was setting values for the Shadowed ReadOnly (access change!) ValueMember and DisplayMember causing a compiler error. You could fix this manually, but that's a pain across hundreds of small data entry forms, so I tried setting the same SerialVis.Hidden on the Shadows Property definitions. Now it seems to be design-worthy, compiling and even works when you run the software... Completely circumventing the Design-time issues I mentioned in the initial post.

So that was a little crazy. I refuse to admit how long that took me to work out. Of course part of my problem was having no prior exposure to this whole Serialization concept. Like I said, I just wanted a "stop it" switch!

Thanks! I hope my programmatic constipation (and resolution!) helps someone else out in the future.

[_HAWK_]

Glad it's fixed! =)