REPRO: Controls disappear from the Windows Forms Designer

[Dmitriy Lapshin [C# / .NET MVP]]

Hi all,

It seems that I have found one case when the Windows Forms desginer silently
removes controls from a form. The sequence of steps that would cause the
designer to silently kill a control is as follows:

1. Create a simple user control that would successfully compile and run
2. Create a form and add the control to the form in the designer
3. Now modify the control to throw an exception in its constructor and
re-compile the project.
4. Open the form in the designer. The control should disappear.

 

[Mike in Paradise]

This is a pain when developing multi layered controls.
AnyWork arounds at this is really starting to become a
problem for me.

Thanks...

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hi Mike,

You might want to read a reply from a Microsoft representative posted in the
microsoft.public.vsnet.ide newsgroup in the same thread.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

This is a pain when developing multi layered controls.
AnyWork arounds at this is really starting to become a
problem for me.

Thanks...

-----Original Message-----
Hi all,

It seems that I have found one case when the Windows Forms desginer silently
removes controls from a form. The sequence of steps that would cause the
designer to silently kill a control is as follows:

1. Create a simple user control that would successfully compile and run
2. Create a form and add the control to the form in the designer
3. Now modify the control to throw an exception in its constructor and
re-compile the project.
4. Open the form in the designer. The control should disappear.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

.

 

[Christopher Morgan]

Well sure.

First, controls should never delibrately throw an exception in its
constructor. Throwing an exception is a defense mechinish to allow a
control to preserve its integrity of state at all times. To do so in a
constructor denys the consumer of the control completely since the "new
ControlXXX()" code never finishes.

There seems to be two issues. What to do with bad input parameters to a
constructor, and the designer "silently" throwing away the control. For the
former, set an error state that the consumer can later retreive, and for the
later, carefully scrutinize the designer when you first bring up newly
developed controls. When I developed controls, I test them by creating them
at run-time using a tester program. Only after they have demonstated
stability do I attempt to create them in the designer. Even then, I
carefully watch so if there is a problem, I can close the ill-formed form
without saving. The corresponding code view text is still preserved. Then
I debug the problem cuasing the exception, until the code executes properly
(being careful not to open the form is design view, code view only), then
finally try to open once agian in the designer.

The designer should be noisier about problem controls in design view. I
have clicked so fast sometimes, that I inadvertly saved the form with my
errant controls removed beecause I failed to notice there was a deisgn-time
problem.

Chris Morgan
OnRamp Technologies, Inc.