That nasty DesignMode issue… again… and again...
For all those I know who keep asking this question... too often (^_^).
Microsoft is not all seeing. They are not omnipotent, despite what they may blag about in their marketing and sales propaganda. Being a hardcore user of their technologies for a long time has given me the ability to say that with some conviction. For instance, some of the bugs features that occur in their work astound me. Like the one where under certain circumstances, when the moon is high you can create a ctor (in c# 2.0) that needs to access a property within the same class (due to functionality encompassed there-in) and the debugger will simply skip over it entirely (although the property will be run anyway) simply because of a missed ‘nop’ opcode at compile-time. You would have thought that would have been picked up early.
Another obvious one is the subject of this missive… the DesignMode property (on the ISite interface, courtesy system.componentmodel.component).
There are times when it is necessary to create custom WinForm controls, sometimes inheriting other controls (i.e. Panel) or sometimes inheriting directly off Control, or even inheriting other custom controls. Sometimes control logic decisions need to be made within the component that say what happens at Design-Time or Run-Time. These things are not always the same – in-fact rarely so. So would it surprise you to know that the DesignMode property does not work for the child controls of a form? It always returns false.
This has caused quite some consternation on the internet, and Microsoft do not have an official work around for this quite common experience. The workaround out there on the internet for this error is usually something like this:
///
/// Indicates if the current view is being utilized in the VS.NET IDE or not.
/// The similarly-named .Net framework property for a UserControl will only
/// show that its related object in is DesignMode only if the immediate parent
/// is viewed in the IDE. For instance, if UserControl A has UserControlB placed
/// on it, and UserControl B has UserControlC placed on it, and UserControl A
/// is being viewed in the IDE, UserControl C will normally register its
/// DesignMode flag as false. This overridden implmentation of DesignMode will
/// utilized a different method in determining this.
///
public new bool DesignMode
{
get
{
return (System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv");
}
}
(Above snippet courtesy of Mark Jordan – chosen as it’s the best presented)
However the above solution has a nasty tendency to fail quite horribly if you are working in a different IDE, or even version of .NET. It is not desirable, and I’d say too ambiguous. Some of the other workarounds are so dire that I won’t let them grace this blog.
YET! All is not lost. (How did you guess I was going to have a better solution?)
When this horrid little problem first reared it’s postuled little head a couple of years ago, I took it upon myself to try and find out why DesignMode was failing. Microsoft was coming up short with an answer, and no-one out there seemed to know either. So I whipped out Lutz Roeder’s Reflector and went for a snoop. It may surprised you to know that while the ISite interface (And all it entails) are available at the time a control is added to it’s parent, the actual ISiteDesignMode value is not assigned. This is a little odd considering that only Controls can be added anyway. Also that the DesignMode property itself is protected (not Public as it could have been to help here); so any chance you think right now you may have of navigating the parent hierarchy until you find the parent Form and retrieving the DesignMode that way… your horribly mistaken. The only OTHER route is a nasty reflection hack (and YES, this form of hack was a suggested work around by another individual – yeuck!). Something that seems a little OTT when there has to be a much better solution to this issue.
Well. There is. Within the System.ComponentModel namespace is a nice little class called ‘LicenseManager’. It has a handy static function within it called ‘UsageMode’. It returns an enumerated value from ‘LicenseModeUsage’ with two options. Guess what they are!?
No. I’m not joking.
Yes, they work under all tested circumstances (so long as the licensing model of the framework is used correctly – which most of you out their will not even think about).
Why doesn’t Microsoft tell everyone complaining about the DesignMode issue?
No idea. Upon asking someone I know on the C# development team on IRC, they told me that they didn’t know either. He informed me that he will chase it up for me. I look forward to his reply to this quirky issue.
Either way… here is a quick usage example:
if(LicenseManager.UsageMode == LicenseUsageMode.Designtime)
{
// design time only stuff
}
else
{
// runtime only stuff.
}
Not rocket science is it?
If Licensing is an interest or a worry to you, here is the info: How to: License Components and Controls. But I doubt it will be an issue unless you want to ban design time access to your component anyway.