469,643 Members | 1,800 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,643 developers. It's quick & easy.

WinForms: DesignMode property is wrong!

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...
Jul 21 '05 #1
2 7190
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...

Jul 21 '05 #2
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...

Jul 21 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Tiago Barbutti | last post: by
3 posts views Thread by Galore | last post: by
2 posts views Thread by Malleier Alfred | last post: by
29 posts views Thread by Charles Law | last post: by
1 post views Thread by Paul W | last post: by
2 posts views Thread by Lecture Snoddddgrass | last post: by
2 posts views Thread by Simon Rigby | last post: by
2 posts views Thread by graeme g | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.