> Carlo,
>
> I suspect that you are going to need to use ShouldSerialize so the
> design-time environment knows what to do.
>
> At any rate, if you Google for "color serialize .Net" you will get a bunch
> of articles that discuss this topic, including:
>
> http://msdn.microsoft.com/msdnmag/issues/03/05/Design-TimeControls/default.aspx
>
> http://www.codeproject.com/soap/xmlsettings.asp
>
> http://www.informit.com/guides/content.asp?g=dotnet&seqNum=212
>
>
> Kerry Moorman
>
>
> "Carlo, MCP" wrote:
>
>> Hi,
>>
>> Sorry for posting twice, but I hope in your comprehension. Please help
>> me!
>>
>> I'm troubling from months with a serious serialization problem that I'm
>> not
>> able to solve. I try to describe as simply
>> as I can.
>>
>> 1) I have a class tha does something with colors. All default values are
>> obviously NOT serializad. Instead, they are serialized when they are
>> different from those of default. Sample:
>> Class ColorClass
>> Private mBackground=Color.White
>> Public Property Background
>> 'Wil be serialized if mBackground not equals to Color.White
>> End Property
>> End Class
>>
>> 2) I have other classes (specifically they are components) that includes
>> some properties linked to the above ColorClass. These classes use one or
>> more instances of the ColorClass for their pourposes, setting appropriate
>> colors each time for each element of the component. Sample:
>> Class MyComponent
>> Private MyTitleBackg as ColorClass
>> Public Sub New()
>> MyTitleBackg .Background=Color.Green 'Here default of ColorClass
>> changes: will be serialized
>> End Sub
>>
>> <DesignerSerializationVisibility(DesignerSerializationVisibility.Content)>
>> _
>> Public Property MyTitleBackg
>> 'Get, Set, etc.
>> End Property
>> End Class
>>
>> If, at design-time, I change MyTitleBackg of MyComponent to Color.Red,
>> new
>> value (Color.Red) WILL be correctly serialized since it is different from
>> BOTH the default of ColorClass and the default of MyComponent.
>>
>> But here is the problem: if, at design-time I change
>> MyComponent.MyTitleBackg to Color.White, the new value Color.White) WILL
>> be
>> NOT serialized, and regenerating assembly causes MyComponent.MyTitleBackg
>> switch back to Color.Green.
>> What happened? New value assigned at design-time (Color.White) is equal
>> to
>> the default of ColorClass, and therefore it is NOT serialized; after
>> regeneration, the designer reads and set MyComponent.MyTitleBackg to the
>> default color of the current instance of MyComponent (Color.Green).
>>
>> This is a problem, because I want MyComponent.MyTitleBackg.Background
>> White,
>> NOT Green!
>>
>> I confess that has not be simple understand the logic behind the problem,
>> especially inside a medium-complessity class hierarchy. Please note that
>> the
>> problem occours with any type, non only colors.
>>
>> A solution should be force serialization by setting
>> ShouldSerializexxx=True
>> (for every property) or by deleting defaults, but I don't consider this a
>> solution: it's a brutality.
>>
>> Ok, if is there a way to avoid this annoyng mechanism, I've not found it.
>>
>> Please help me... Thank you.
>>
>> Carlo
>>
>>
>>
>>
>>

"Carlo, MCP" wrote:

> Hi,
>
> Sorry for posting twice, but I hope in your comprehension. Please help me!
>
> I'm troubling from months with a serious serialization problem that I'm not
> able to solve. I try to describe as simply
> as I can.
>
> 1) I have a class tha does something with colors. All default values are
> obviously NOT serializad. Instead, they are serialized when they are
> different from those of default. Sample:
> Class ColorClass
> Private mBackground=Color.White
> Public Property Background
> 'Wil be serialized if mBackground not equals to Color.White
> End Property
> End Class
>
> 2) I have other classes (specifically they are components) that includes
> some properties linked to the above ColorClass. These classes use one or
> more instances of the ColorClass for their pourposes, setting appropriate
> colors each time for each element of the component. Sample:
> Class MyComponent
> Private MyTitleBackg as ColorClass
> Public Sub New()
> MyTitleBackg .Background=Color.Green 'Here default of ColorClass
> changes: will be serialized
> End Sub
> <DesignerSerializationVisibility(DesignerSerializationVisibility.Content)>
> _
> Public Property MyTitleBackg
> 'Get, Set, etc.
> End Property
> End Class
>
> If, at design-time, I change MyTitleBackg of MyComponent to Color.Red, new
> value (Color.Red) WILL be correctly serialized since it is different from
> BOTH the default of ColorClass and the default of MyComponent.
>
> But here is the problem: if, at design-time I change
> MyComponent.MyTitleBackg to Color.White, the new value Color.White) WILL be
> NOT serialized, and regenerating assembly causes MyComponent.MyTitleBackg
> switch back to Color.Green.
> What happened? New value assigned at design-time (Color.White) is equal to
> the default of ColorClass, and therefore it is NOT serialized; after
> regeneration, the designer reads and set MyComponent.MyTitleBackg to the
> default color of the current instance of MyComponent (Color.Green).
>
> This is a problem, because I want MyComponent.MyTitleBackg.Background White,
> NOT Green!
>
> I confess that has not be simple understand the logic behind the problem,
> especially inside a medium-complessity class hierarchy. Please note that the
> problem occours with any type, non only colors.
>
> A solution should be force serialization by setting ShouldSerializexxx=True
> (for every property) or by deleting defaults, but I don't consider this a
> solution: it's a brutality.
>
> Ok, if is there a way to avoid this annoyng mechanism, I've not found it.
>
> Please help me... Thank you.
>
> Carlo
>
>
>
>