Alberto said:
If you delete the "partial" declaration of the class and the
InitializeComponent() call, it will compile.
The app will compile but if you try to insert this control in a form you
will see the error.
And to clarify to other readers of this thread: the error is displayed
as an alert, presented to the user at the moment the control is added to
the form.
You should have provided a concise-but-complete code example, but I was
able to reproduce the problem using the incomplete example you offered.
As for the error, it's telling you exactly what it looks like it's
telling you: your object has a property that can't be serialized.
As Mike said, the Designer requires that public properties for a Control
class used in the designer be serializable. For simple properties, such
as strings, ints, etc. the Designer can handle those fine. But it can't
automatically generate initialization code for more complex properties,
such as "List<Nodo>".
You have two choices: disable serialization for those properties, or
support serialization for those properties. What you _can't_ do is fail
to disable serialization for those properties, but also fail to provide
serialization support for those properties. In that case, the Designer
will attempt to serialize the properties, but fail because you haven't
provided the necessary support.
If you want to learn about support serialization, you can read the MSDN
documentation on ISerializable and/or the "[Serializable]" code attribute.
If you simply want to disable serialization for those properties, add
the "[DesignerSerializationVisibility]" attribute, with the "Hidden"
option, so that the Designer will know to ignore those properties (of
course, any initialization of those properties will have to be done
explicitly in your own code). For example:
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public List<Nodo> Hijos
{
get { return hijos; }
set { hijos = value; }
}
(Note that the "[NonSerialized]" attribute Mike mentioned is for fields
only...for properties, you need the above).
Personally, those properties seem suspect to me design-wise anyway.
Allowing client code direct access to a complex data structure defining
relationships between that instance and others is generally a bad idea.
So it may be a better way to fix the problem is simply to not expose
those lists in that way in the first place.
But if you feel you must, you need to correctly deal with the Designer's
dependencies on the properties.
Pete