WinForms: DesignMode property is wrong!

[Lecture Snoddddgrass]

Hi,

When I create a UserControl-derived object, I often expose various
public properties. One of the things that I hate about the WinForms designer
is that if I decide to embed one of these controls in a form (or another
control), the designer likes to "touch" each of my custom properties --
either by trying to "set" it to a default value (null/zero) or trying to
"get" it's value. This is a real PITA because often times calling "get" on
these properties results in my code attempting to connect to another server,
retrieve some information, cache it, etc... While this is great at runtime,
it just doesn't make sense at design-time. Trying to "set" these properties
causes similar problems.

I make it a regular practice in the get/set handlers of my public
properties to always check the "DesignMode" property -- and if it's true,
I'll immediately return zero/null for the "get" or simply return immediately
for the "set"... This seems like a simple workaround for VS.NET's irritating
design-time behavior. The problem is that DesignMode doesn't always return
the correct value. It sometimes returns false even though the control is
being used in design mode. This happens when my UserControl-derived object
is placed in another UserControl-derived object which is then placed in
either a form or another control. In this nasty case, the DesignMode
property of my control will always return false even if my control is being
used in design mode. I'd be happy to write my own recursive DesignMode
checker that looks up the stack of parent controls... but even this is
impossible because DesignMode is a protected property, not public, so my
control has no way of checking the DesignMode property of its parents!

Is there a way around this tedious bug? This DesignMode thing is killing
me.

Thanks...

[Claes Bergefall]

Recursive DesignMode checker:
http://groups.google.se/gr**********....gbl&lr=&hl=sv

/claes

"Lecture Snoddddgrass" <ma***@hamburg.fry> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...

Hi,

When I create a UserControl-derived object, I often expose various
public properties. One of the things that I hate about the WinForms designer is that if I decide to embed one of these controls in a form (or another
control), the designer likes to "touch" each of my custom properties --
either by trying to "set" it to a default value (null/zero) or trying to
"get" it's value. This is a real PITA because often times calling "get" on
these properties results in my code attempting to connect to another server, retrieve some information, cache it, etc... While this is great at runtime, it just doesn't make sense at design-time. Trying to "set" these properties causes similar problems.

I make it a regular practice in the get/set handlers of my public
properties to always check the "DesignMode" property -- and if it's true,
I'll immediately return zero/null for the "get" or simply return immediately for the "set"... This seems like a simple workaround for VS.NET's irritating design-time behavior. The problem is that DesignMode doesn't always return
the correct value. It sometimes returns false even though the control is
being used in design mode. This happens when my UserControl-derived object
is placed in another UserControl-derived object which is then placed in
either a form or another control. In this nasty case, the DesignMode
property of my control will always return false even if my control is being used in design mode. I'd be happy to write my own recursive DesignMode
checker that looks up the stack of parent controls... but even this is
impossible because DesignMode is a protected property, not public, so my
control has no way of checking the DesignMode property of its parents!

Is there a way around this tedious bug? This DesignMode thing is killing me.

Thanks...

[news.microsoft.com]

Actually DesignMode property always return false in object constructor.
(yes, msdn doesnt include this) In practice you must place minimal code in
constructor, i'm overriding refresh method to workaround.

"Lecture Snoddddgrass" <ma***@hamburg.fry> wrote in message
news:eG**************@TK2MSFTNGP12.phx.gbl...

Hi,

When I create a UserControl-derived object, I often expose various
public properties. One of the things that I hate about the WinForms designer is that if I decide to embed one of these controls in a form (or another
control), the designer likes to "touch" each of my custom properties --
either by trying to "set" it to a default value (null/zero) or trying to
"get" it's value. This is a real PITA because often times calling "get" on
these properties results in my code attempting to connect to another server, retrieve some information, cache it, etc... While this is great at runtime, it just doesn't make sense at design-time. Trying to "set" these properties causes similar problems.

I make it a regular practice in the get/set handlers of my public
properties to always check the "DesignMode" property -- and if it's true,
I'll immediately return zero/null for the "get" or simply return immediately for the "set"... This seems like a simple workaround for VS.NET's irritating design-time behavior. The problem is that DesignMode doesn't always return
the correct value. It sometimes returns false even though the control is
being used in design mode. This happens when my UserControl-derived object
is placed in another UserControl-derived object which is then placed in
either a form or another control. In this nasty case, the DesignMode
property of my control will always return false even if my control is being used in design mode. I'd be happy to write my own recursive DesignMode
checker that looks up the stack of parent controls... but even this is
impossible because DesignMode is a protected property, not public, so my
control has no way of checking the DesignMode property of its parents!

Is there a way around this tedious bug? This DesignMode thing is killing me.

Thanks...