How do I keep Visual Studio's Windows Forms Designer from deleting controls?

Question

With several forms of mine, I occasionally run into the following issue: I edit the form using the designer (Visual Studio 2008, Windows Forms, .NET 2.0, VB.NET) to add comp

Answer 1

I've found the DesignMode property sometimes produces an unexpected result (Daniel's answer). Below is a property I have on my base control class (most controls I created inherit from this), the comments should indicate the 'reason' for what looks like hacky code, but essentially this is much more reliable than DesignMode on its own.

    /// <summary>
    /// Indicates if the current view is being utilized in the VS.NET IDE or not.
    /// </summary>
    /// <remarks>The DesignMode property for a UserControl object will show that it is in DesignMode
    /// only if the immediate parent is viewed in the IDE; if it is a grand child of the object that is being viewed in the IDE,
    /// then the DesignMode property will not be true.
    /// This is a workaround</remarks>
    public bool InDesignMode
    {
        get
        {
            // Site.Design mode sometimes produces a better result.
            if (DesignMode || Site != null && Site.DesignMode)
                return true;
            Control parent = Parent;
            while (parent != null)
            {
                if (parent.Site != null && parent.Site.DesignMode)
                    return true;
                parent = parent.Parent;
            }

            // Note: I am not 100% sure about this one; I need to double check
            // if in design mode then entryAssembly will be null. This check is 
            // needed because DesignMode property is only true for the control
            // that is actively being designed, so child controls will be false...
            // We do check the Parent heirarchy in InDesignMode but in some 
            // cases Parent will not be set before the check is required.
            var entryAssembly = Assembly.GetEntryAssembly();
            if (entryAssembly == null)
                return true;

            return false;
        }
    }

Answer 2

If you can reproduce the problem, then you can determine whether or not the cause is an exception. Start a second instance of Visual Studio and use "Tools->Attach to Process" to attach to the first one. Then proceed to reproduce the problem, and the code should break when the unhandled exception is thrown. Information about other exceptions (possibly handled) will be visible in the Output window.

Answer 3

Another piece of good practice, do not delete default form constructors. IDE uses them, even when your logic do not. Locking is also useful.

Answer 4

This is not an answer to your question, but remember that you should use "DesignMode" in loads. This avoids weird unexpected behaviors during design time.

private void EureFormAbm_Load(object sender, System.EventArgs e)
{
    if (!DesignMode)
    {
        // Your code
    } /* if */
}

or

private void EureFormAbm_Load(object sender, System.EventArgs e)
{
    if (DesignMode)
        return;
    // Your code
}

Answer 5

It is not a real answer for you, but here are some more pointers I've found helpful..

A) See @Daniel Dolz's answer. I wholeheartedly recommend you ALWAYS do what he's recommending except when you avoid putting non-UI code (or any code) in Form_Load altogether. This actually solves a lot of problems, but especially those exceptions popping up in designers and slow designer performance.

B) As much as humanly possible:

Never edit the designer.cs in Windows Forms.

OK, sometimes you have to, but it's not someplace to do regular development. Third-party controls will have bugs that require you to do so, but it should be an exceedingly rare day when you're making a direct change in the designer file. One way to help manage this is that if you don't want the designer automatically adjusting something, copy it over to your regular .cs file. That doesn't cover everything, but keep it in mind.

C) Also, do you know you can Lock the layout via the IDE to prevent stray mouse clicks from goofing everything up on you? This will preempt some of these "automatic updates" you're running into.

Parting Shot I worked on a large Windows Forms project for more than two years immediately prior to my current project, and all I can say is until we put an end to people editing the designers except for very minor edits and required them to put in the DesignMode checks, we had nothing but problems. Coming off of web projects, we have a hard time with this idea because we're so used to editing markup, but the designer.cs isn't the same as markup.

Answer 6

I've seen this happen with Visual Basic 6.0 and early .NET when the OS was having problems. We had to do a reboot and repair.