Selfelected

DesignMode in Visual Studio, inheritance, process name and a work around

The text and code below is only tested for Winform. WPF might behave differently; hopefully behaves differently.

I won’t go into any details on why the ISite.DesignMode is good and sometimes even crucial to have. It is much better done in the link at the bottom.

First out there is unfortunately a caveat with DesignMode, it doesn’t work with inherited forms and user controls. This is a problem since I always inherit from the base form in my projects and tell others to do the same. It also doesn’t work inside the form’s or the user control’s constructor and then by any method that is called by the constructor. Long call chains to might make this hard to track down.
Secondly there is another way to check for design mode and that is to check for the LicenseManager.UsageMode but this in turn doesn’t work in event handlers.
Thirdly one can set a flag in the base Form and base UserControl. But this doesn’t solve the problem since we cannot be sure with what to set this value.
Fourthly is a workaround where one can check for the name of the process itself which is Visual Studio’s process name (devenv) in case of design mode. This process name might change in future releases of Visual Studio and is also different for other IDEs.
Fifthly is other process information like the name of the module and stuff. Check into the Process and you’ll see that the app is called MyApp.vshost.exe while being debugged.

The fourth solution (processname=devenv) seems to be the most viable but I believe there is something useful in the fifth (other process information). There must be a way to notice that the name of all your code doesn’t match the name of the running environment; namespace, assembly name, whatever. I still haven’t figured out how though.

Below is some code to copy-paste.
It is not 100% correct though since the DesignMode property isn’t virtual. This might end with some really tough-to-track-down bugs where one iterates the forms but don’t get the overloaded DesignMode flag. The code also doesn’t promise to work forever since there is a magic string naming the name of the Visual Studio process.

public partial class MyAppForm : System.Windows.Forms.Form{protected new bool DesignMode{get{return HelperMethods.IsDesignMode(this);}}}

public partial class MyAppUserControl : UserControl{protected new bool DesignMode{get{return HelperMethods.IsDesignMode(this);}}}

class HelperMethods{public static bool IsDesignMode(System.ComponentModel.Component x){var site = x as System.ComponentModel.ISite;return( null == site ? false : site.DesignMode ) ||System.ComponentModel.LicenseManager.UsageMode == System.ComponentModel.LicenseUsageMode.Designtime ||System.Diagnostics.Process.GetCurrentProcess().ProcessName == "devenv";}}

The code above is also in pastebin for easier copy-paste.
A good article is here: http://dotnetfacts.blogspot.com/2009/01/identifying-run-time-and-design-mode.html
There is a description of how to debug this here: http://brennan.offwhite.net/blog/2006/08/30/design-time-debugging-aspnet-20-in-visual-studio-2005/

Sortable IBindinglist

Datagridviews in dotnet work well with datasets.  They work less good with “normal” objects; for instance sorting is much more of a hassle to implement.

The sorting problem is solved nicely in this http://groups.google.co.uk/group/microsoft.public.dotnet.languages.csharp/msg/2b7528c689f9ef84 piece of code.  It is more or less just to copy the code and violà, a sortable object list.

Change the name of splitContainer1

Dotnet WinForm has a control called Split container.  It is a nice control for making forms scale properly when the user changes their sizes.

Now there is a bug in Vsnet that surfaces when you put split containers in each other and do not change their default names.  splitContainer1, splitContainer2 etc.

The remedy is easy: change the name as you create the split containers.

Update:
The bug reveals itself by stopping the designer from rendering the form; instead a text like “a control cannot be in itself” shows.
If that happens you are not totally screwed even though there is no clue to what to do.

Open the .designer file and remove a split control. I have no idea of how to find out which split control messed up. Just remove one. Open the graphical designer (possibly close and open). Repeat until you have a form like usual but the controls you have put on the split controls are gone. Don’t dispair, they are not gone – they are just not placed anywhere.

Drop a split control on the graphical designer. Add controls to it through myListbox.Controls.Add( myTextbox )…. If you do it properly – like adding the right controls to the correct new split control everything is like before. Except possibly event handlers om the split controls. At least you didn’t have to remake the whole form.