OK, I have a C# class. It's designable (ie. derives from Control), and
has a public property that has a GET method.
private string _stringA = "";
[System.ComponentModel.Browsable(false)]
public string StringA
{
get
{
// Force an exception.
Label l = null;
l.Text = "Hello";
return _stringA;
}
}
I don't want this property visible at design-time, so I add:
[System.ComponentModel.Browsable(false)]
In theory, whilst in design-mode, the GET method for my property should
never be called (let's also assume there's no progammatic code in the
constructor to call it, etc, either).
I test this by hard-coding an intentional exception into the GET method.
I then attach a 2nd VS.NET instance to the one I'm designing in, set
it trap C# exceptions, and let it continue.
Whenever the designer in the main instance hits an exception, the 2nd
instances of VS.NET will break, hopefully at the problem code.
If you create a simple usercontrol with this scenario, it'll never
exception. However, in a number of other cases it **does** exception.
I contend that it shouldn't, as it should NEVER be calling the GET
method. For example, you have UserControl1 in ClassLibrary1. If you
derive from that class, to UserControl2 in ClassLibrary2, you see the
2nd VS.NET always trap the exception, ie. the call to the GET method. Why?
Now, you can stop this, by adding the attribute:
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
Now, I totally understand that by adding this, you're forcing the
code-serializer to NOT serialize the property. However, if you don't
have this property, and only have [Browsable(false)] it's totally
inconsistent as to whether the GET method is called or not.
So my question is, why does it call the GET method in some cases, and
not others?
This sounds unimportant, but in complex designable classes, it's a huge
issue.
Sean
|
Similar Threads
