tags:

views:

338

answers:

4

Hi,

I have subclassed a Treeview and on instantiation it loads a new ImageList (and the associated Images).

Whenever I switch to the designer view, it's also trying to run this code, however the images aren't in the designer's path, so it crashes. I ended up putting in a hack to see if the current directory is "Visual Studio", then do nothing... but that's so ugly.

I find this happening for other things. If a control is trying to use objects during load/initalization that are only available while the program is running, then the Design View cannot bring up the control.

But is there a way to get around this?

I guess what I'm hoping for is having a try/catch for the Designer (only) with the ability to ignore a few errors I know will be happening (like FileNotFoundException, etc.).

Thanks

+4  A: 

Everything that inherits from System.Windows.Forms.Control has a DesignMode property that returns a boolean indicating if you are in design mode or not. You could use this to determine when to/when not to load external resources.

Sean Bright
+1  A: 

Usually it is better to move the loading of these resources to an override of OnLoad as they are rarely required directly at construction. This fixes the issue you are seeing and means that only trees which get displayed at least once will perform these additional resource loading steps.

Otherwise, you can just exclude these steps during design time by checking the DesignMode property and acting accordingly.

Jeff Yates
A: 

Thanks for pointing me in the right directioon guys.

I had tried registering to the OnLoad event, but that event is triggered when the Design View comes up, so that didn't quite work for me (am I doing something wrong?).


Anyway, I looked a bit more into the DesignMode property. It can only work for Controls, and sometimes your object may not even be a control.

So here's the answer I prefer:
if (LicenseManager.UsageMode == LicenseUsageMode.Designtime) {
// design-time stuff
} else {
// run-time stuff
}

Found it here.

Ivan
+1  A: 

This is a fine pattern to use if you're making a control library with a sample of images when shown in the designer or hook ins to other designer features but as a pattern for development I'm not sure it's very effective.

I would suggest shifting your "business logic" (in this case your loading of certain images into a treeview) outside of the bounds of your treeview control. In your case I would place the logic within the Load event of the form that the control is inside:

public void Load(object sender, EventArgs e)
{
    string path = "c:\somePath\toAwesome\Images";
    myFunkyTreeView.AddImages(path);
}

For larger apps I personally think you want to shift the logic even out of the forms themselves, but this is debatable measure as it requires additional plumbing as a trade-off for the flexibility this provides.

Quibblesome
+1: subclassing WinForms controls to do business-specific view logic always ends in an unmaintainable disaster. Yuck.
Michael Meadows