Home Dashboard Directory Help
Search

DesignMode property doesn't behave as anticipated by Jonathan Dyke


Status: 

Closed
 as By Design Help for as By Design


4
0
Sign in
to vote
Type: Bug
ID: 309922
Opened: 11/12/2007 5:53:30 PM
Access Restriction: Public
Duplicates: 314048
2
Workaround(s)
view
4
User(s) can reproduce this bug

Description

The DesignMode property is frequently used to prevent the designer from running code the should only be executed at runtime. This works fine for both forms and user controls.

After adding a usercontrol to a form, the story changes. Opening the form in the IDE continues to produce the expected behavior, however the usercontrol now behaves as if it is runtime. The code that is supposed to be runtime-only is now executing in the designer anyway. This can lead to a number of performance issues and bizarre IDE errors, particularly when the code accesses a database (and has to wait for a connection to timeout) or tries to access an object (that may or may not have been instantiated).

Restructuring the code is always an option, however this type of code is almost impossible to find unless it does something that is either time consuming or error-prone at runtime. Most developers would simply overlook it as the cause of their IDE crashes because of the designmode block anyway.
Details
Sign in to post a comment.
Posted by Microsoft on 5/27/2008 at 8:51 PM
Thanks for your feedback on the .NET Framework!

We are able to reproduce this issue in our environment and consider rolling in a fix to this issue in next release.

Many customers have found it useful to discuss issues like this in the forums (http://forums.microsoft.com/msdn/default.aspx?siteid=1) where Microsoft and other members of the community can suggest workarounds.

Please keep the feedback comming.

Thanks,
UIFx Team
Posted by Jonathan Dyke on 11/14/2007 at 8:29 AM
Thanks to Stephan Smetsers for the work-around. After overriding the designmode property in my base usercontrol to implement his code, everything behaves as expected.
Posted by Microsoft on 11/13/2007 at 8:01 PM
Thanks for your feedback.

We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team
Posted by Microsoft on 11/13/2007 at 5:50 PM
Thank you for your feedback. We are currently investigating. The investigation process normally takes 7-14 days. If this issue is urgent, please contact support directly (see http://support.microsoft.com).

If at any time your issue is closed unsatisfactorily, you may edit your issue via Connect and change the status to “Active.”

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by BlueRaja on 4/22/2010 at 10:42 AM
Something less hackish (from the comments of this page http://decav.com/blogs/andre/archive/2007/04/18/1078.aspx ):
        /// <summary>
        /// The DesignMode property does not correctly tell you if
        /// you are in design mode. IsDesignerHosted is a corrected
        /// version of that property.
        /// </summary>
        public bool IsDesignerHosted
        {
            get
            {
                Control ctrl = this;

                while (ctrl != null)
                {
                    if ((ctrl.Site != null) && ctrl.Site.DesignMode)
                        return true;
                    ctrl = ctrl.Parent;
                }
                return false;
            }
        }
Posted by Stephan Smetsers on 11/13/2007 at 12:59 AM
This problem also occurs when you want to have designtime/runtime specific behaviour in the constructor of a control. Because the Site property (that holds the DesignMode property) is assigned after the control is being created; one cannot use it in the constructor code.

I always use the following code to check whether we are in designmode:

if (System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv")
{
// we are in designtime
}
else
{
// we are in runtime
}

A big advantage is that this code also works at places where one cannot get a reference to the Site property of a visual control.
Using this technique it is no longer required to pass the designmode-flag as a parameter in all methods that need this information.

Although this workaround works ok, I would like Microsoft to create a static .NET class holding the DesignMode property, so we can access this information at all times, at all places we like.


Kind regards,

Stephan Smetsers