3

I am creating a series of window mockup templates based on the excellent Mockups library available on CodePlex.

I'm using their BaseMockup as the base for my control as well, and I followed the same outline of the steps listed here for sub-deriving from existing controls (Create a new empty class, add your default style to /Themes/generic.xaml, etc.)

The control is working great - the only thing is that it doesn't show up in the Assets library. I think this is because it's sub-derived, or because I need some attribute (the equivalent of the ToolboxItemAttribute for WinForms controls? ... which didn't work) to get it hooked up.

When I modify the code to derive directly from Control, it shows up - no custom attribute necessary. Of course that defeats the purpose of what I'm trying to do though...

The only thing I can find are several articles telling me to muck with registry keys, and none of them are clear or suggest a definitive way to do this with Blend 4. That last one advertises as a Blend 4 tips article, but admits at the end that it plagiarizes the content from the other two (for Blend 3).

Is that my only option - register my DLL? Is there a better way to do this?

mcw
  • 3,500
  • 1
  • 31
  • 33

3 Answers3

1

A while ago I wrote a blogpost about this. I've included a .reg file and a .bat file for setting up the register and some directories. I think that's what you are looking for.

Sorskoot
  • 10,190
  • 6
  • 55
  • 98
  • This is really cool, but unfortunately it doesn't solve the question. Even though I can see my Control/UserControl derived controls in the assembly, this specific sub-derived control still doesn't show up. – mcw Aug 17 '11 at 18:37
1

I believe you do need to muck with registry keys. Specifically,

32 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx

64 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx

Create a new key with the name of your control assembly. Then edit the Default string value under this key and set the value to the directory where the control assemblies are installed. See here for a full example (using the Silverlight paths).

mcw
  • 3,500
  • 1
  • 31
  • 33
Mike Post
  • 6,355
  • 3
  • 38
  • 48
  • Thanks - this is the proper path. (I made an edit because the backslash dot in between Microsoft and NET Framework was treated as an escaped dot... doh!) – mcw Aug 17 '11 at 18:39
  • Doh! Guess it got swallowed up in the editor, thanks for that. :) – Mike Post Aug 17 '11 at 19:45
  • Sorry, I unaccepted your answer - but only because I found the attribute I was looking for. Thanks again though! – mcw Aug 18 '11 at 18:42
1

Found it - there is an analogue attribute after all, it's ToolboxBrowsableAttribute.

You have to go through a little more rigmarole to get it set up, but it works great - no registry mucking necessary. It requires creating a designer metadata provider class, attributing your assembly so it's designer-discoverable, and then adding the attributes to your sub-derived controls inside your metadata provider.

Make sure you choose the appropriate version of the page for your version of Visual Studio, because the interface changes a good bit between 2008 and 2010.

This article on CodeProject has some good, real-world examples of setting this up. They're all in the 2008 style though, so bear that in mind if you're using 2010.

mcw
  • 3,500
  • 1
  • 31
  • 33