Error in Visual Studio 2010 inherited Form property persistence?

Question

1.80/5 (2 votes)

See more:

VS2010

I am inheriting one WinForms Form from another. I have a property in the base form:

C#

[Browsable(true)]
[Category("Appearance")]
[DefaultValue(false)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
public bool ShowMeLabelVisible
{
    get { return ShowMeLabel.Visible; }
    set { ShowMeLabel.Visible = value; }
}

public bool ShouldSerializeShowMeLabelVisible ()
{
    return true;
}

The generated InitializeComponent() method in the inheriting form sets the property value only when it is true, and does not set the property value when it is false, regardless of the default value specified by the DefaultValueAttribute. This is despite the ShouldSerializeShowMeLabelVisible method indicating the property value should always be serialized. Further, when the form is first shown in the Visual Studio designer, or immediately after a rebuild (including a debug run), Visual Studio shows the property value as true in the Properties window, and the designer acts as if the property were set to true; even if the DefaultValueAttribute is constructed with false, the underlying ShowMeLabel.Visible property is false, and (due to the absence of initialization in IntializeComponent()) the run time value is false.

Can someone give me a hint as to what I’m doing wrong? I would like the property value at design time and at run time to agree, and the designer to look like the run time form.

The environment is VS 2010 version 10.0.40219.1 SP1Rel on Win 7 Pro 6.1.7601 SP1.

Thank you.

Posted 27-Mar-13 9:02am

Brian Hetrick

Updated 27-Mar-13 9:15am

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 27-Mar-13 15:05pm

To start with, you don't show where ShouldSerializeShowMeLabelVisible is used...
—SA

Brian Hetrick 27-Mar-13 15:23pm

ShouldSerialize[PropertyNameHere] is supposed to be called by the designer using reflection; see e.g. Defining Default Values with the ShouldSerialize and Reset Methods.

Sergey Alexandrovich Kryukov 27-Mar-13 15:28pm

No, it is not. This is just your own method, without any attribute. Maybe, that's why you have this problem.
—SA

Brian Hetrick 27-Mar-13 15:32pm

Perhaps you could post a short snippet of how the ShouldSerialize and Reset methods should be used, then. I would greatly appreciate it.

Sergey Alexandrovich Kryukov 27-Mar-13 15:44pm

You know what? I found that even the MSDN sample you referenced above should not work. Worse, if it actually works :-(. It means that Microsoft uses a dirty trick: the method is found by the dirty naming conventions, when the library codes looks at all methods using Reflection and choose the one with then name matching some pattern. No one has any right to do such tricks, even Microsoft. Unfortunately, I already caught Microsoft on such dirty trick, but this one looks the very worst. Fortunately, all my findings like that are related to the ComponentModel. It is extremely lousy and must die. So, please forgive me: I'll never go into this, and would not advise you do go there.

For persistence, I only use either Microsoft Data Contract, which is very good, or my own very similar persistence system, for some extra flexibility. I hope you can also find a work around...

—SA

Brian Hetrick 27-Mar-13 15:57pm

Perhaps you could show how to use Data Contracts to persist designer property values in a WinForms application, then. I would greatly appreciate it.

phil.o 27-Mar-13 15:32pm

Quite hard to guess.

DefaultValue attribute is only used when, in your whatever.designer.cs file, there is no value set for the given property. If there's one, that means it overrides the default value (and you can see that because the said property in the property designer is bolded).

Something I wonder, also, is when you say "The generated InitializeComponent() method in the inheriting form sets the property value only when it is true, and does not set the property value when it is false".
This seems the default behavior for me : if you set the property to true, InitializeComponent() will record it ; otherwise, it will consider it is default value, and thus does not record it.
Does it make sense ?

Maybe I'm missing something from the description of your problem ; or maybe it's your analyze of the problem that is false. If I were you I would make sure the serialization process that is in place is actually executed.

Hope this helps.

Brian Hetrick 27-Mar-13 15:36pm

If I set the property value to true, InitializeComponent() records it, regardless of the value specified in DefaultValueAttribute or even whether DefaultValueAttribute is present at all. Similarly, if I set the property value to false, InitializeComponent() does not record it, again regardless of the DefaultValueAttribute. Finally, Visual Studio seems to interpret the lack of an initializer as indicating a non-default value of true, again regardless of the DefaultValueAttribute.

phil.o 27-Mar-13 15:48pm

OK, now that's more clear. Thanks for taking time to explain.
About the serialization process : did you put a beakpoint in your ShouldSerialize method, or in the method from where the ShouldSerialize method is called ?

Brian Hetrick 27-Mar-13 16:03pm

I just tried putting a breakpoint on it; the breakpoint did not trip. But since the method is called at design time (not run time), that does not particularly surprise me.

Brian Hetrick 27-Mar-13 16:13pm

I did not mention it in the original question, but the code:

<pre lang="c#">[Browsable(true)]
[Category("Appearance")]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
public bool ShowMeLabelVisible
{
get { return ShowMeLabel.Visible; }
set { ShowMeLabel.Visible = value; }
}

public void ResetShowMeLabelVisible()
{
ShowMeLabelVisible = false;
}

public bool ShouldSerializeShowMeLabelVisible ()
{
return true;
}</pre>

gives the same design time results.

Brian Hetrick 27-Mar-13 16:14pm

In summary, neither DefaultValueAttribute() or the alternative Reset and ShouldSerialize methods seem to work as documented.

phil.o 27-Mar-13 16:29pm

Well, I'm afraid I can't help further. I don't have enough time, nor am I motivated, to settle a test project. I hope you will figure this out.

Sergey Alexandrovich Kryukov 27-Mar-13 15:45pm

Please see my comment above, it could give some idea. Pretty unfortunate situation, I think...
—SA

phil.o 27-Mar-13 15:51pm

Indeed. I was not aware of this dirty trick, and would not rely on it, either.

Sergey Alexandrovich Kryukov 27-Mar-13 15:56pm

Good idea, I think. Just in case, we could try if that code sample works...
—SA

phil.o 27-Mar-13 16:06pm

Not sure it will work :) ; the article clearly states that methods should not be used together.

2 solutions

Solution 1

From the link you gave :

Note

Either apply the DefaultValueAttribute or provide ResetPropertyName and ShouldSerializePropertyName methods. Do not use both.

As Sergey stated, do not rely on this dirty trick with method names ; better use the attribute in the first place, and see how it is behaving.

Posted 27-Mar-13 10:02am

phil.o

Comments

Sergey Alexandrovich Kryukov 27-Mar-13 16:39pm

Agree! My 5.
—SA

Brian Hetrick 27-Mar-13 17:13pm

Unfortunately, as I noted, neither the attribute nor the documented "dirty trick" with the methods named after the property name actually work. I'll try again in another question.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Brian Hetrick · Accepted Answer · 2013-03-28T06:25:00

This turns out to be a known bug in the VS WinForms designer; see Problem with inherits form. It affects only properties which are directly backed by the Visible property of components. The solution is to use a variable to hold the intended state of the visibility attribute, manipulate it instead, and set the appropriate control’s Visible property when needed:

C#

private bool _pt1Visible = true;

[Browsable(true), Category("Appearance"), DefaultValue(true)]
public bool Pt1Visible
{
    get { return _pt1Visible; }
    set
    {
        _pt1Visible = value;
        PotentialLabel1.Visible = _pt1Visible;
    }
}

Thank you BonnieB!