none
AutoToolboxPopulate not working

    Question

  • Hi

    One of the great things I liked when beta testing VS 2005 was the AutoToolboxPopulate feature that would populate a special tab in your solution toolbox whenever you create a new Control or Component.

    The feature seems to still be there (seen it in the Windows Forms Designer UI options tab) but it is not working properly.

    Whenever I build my app, the controls built in are not showing up in the toolbox.

    Is it related to the fact that I create simple classes files instead of custom control files (which at the end are just source code files)?

    Thanks

    Amadrias
    Thursday, November 10, 2005 4:12 PM

Answers

  • Ok, after some simple tests, I think I found a bug with this feature.

    I've created a solution and sub folders and winforms projects in the following structure:

    MySolution [Solution Root]
       Folder1
          Folder1.1
             Folder1.1.1
          Folder1.2
       Folder2
          Folder2.1
             Folder2.1.1
             Folder2.1.2

    I've created a win form project in each of these folders with a simple form and added a UserControl to the project (nothing made on code).

    As a result, no one executed the AutoToolboxPopulate feature except the one created at the root of the Solution Structure.
    The other ones do not populate the toolbox.

    Cheers

    Amadrias
    Thursday, November 10, 2005 4:42 PM
  • Based on your description, it seems that we misunderstand where the problem occurs:

    It's not when you add folders to a project, but to a solution.

    Instead of creating right away a project which creates a solution with the same name by selecting a Windows Forms Project from the templates "New Project" menu, I use to create first a "Blank Solution" from the "Other projects" node in the project category tree.

    On top of that, I create a structure to handle references to source code of course then separated by project types (i.e. client, server, common, frameworks...) and folders for storing documents and I also like to have a Binary subfolder per release version that is just suppose to hold my last valid release for testing and comparison references.

    So, just try to follow my steps from a blank solution and tell me if you get the same issue or not... It's maybe related to my computer...

    I still found a workaround for my case: unloading and reloading the project from the solution explorer seems to make things work again.

    Cordially,

    Amadrias
    Friday, November 11, 2005 3:29 PM

All replies

  • I have just tried on my C# express, and it works. I created a new class file, added the code to inherit from UserControl, compiled, and it showed up in the toolbox. Also tried a Component, and it worked, too.
    Thursday, November 10, 2005 4:22 PM
  • Well, yes, I should have been more explicit in my first post.

    I have only one solution for which the feature is not working.
    The only difference I see in this solution is that I have a set of solution directories and not a solution->project direct link in the solution tree.
    Instead, I have:

    MySolution [Solution Root]
       Documents [Folder]
       Source Code [Folder]
          Client App [Folder]
             MySolution.App [Project]

    Thanks

    Amadrias
    Thursday, November 10, 2005 4:26 PM
  • Ok, after some simple tests, I think I found a bug with this feature.

    I've created a solution and sub folders and winforms projects in the following structure:

    MySolution [Solution Root]
       Folder1
          Folder1.1
             Folder1.1.1
          Folder1.2
       Folder2
          Folder2.1
             Folder2.1.1
             Folder2.1.2

    I've created a win form project in each of these folders with a simple form and added a UserControl to the project (nothing made on code).

    As a result, no one executed the AutoToolboxPopulate feature except the one created at the root of the Solution Structure.
    The other ones do not populate the toolbox.

    Cheers

    Amadrias
    Thursday, November 10, 2005 4:42 PM
  • Hi Amadrias --

    I'm trying to reproduce the problem you're seeing.  The AutoToolbox feature doesn't know anything about project structure (it just walks outputs) so I'm surprised that this is the issue. I did the following steps:

    1) Created a Windows Applicaction Project, and added a user control to it [ok]

    2) Created a folders like:

       c:\temp\WindowsApplication1\SubFolder.1
       c:\temp\WindowsApplication1\SubFolder.1\SubFolder.2

    3) Created Windows Control Library projects in Subfolder.1, SubFolder.2.

    4) Go back to the Form1 in the original windows app

    Result: I see 3 user controls in the toolbox, one from each project.

    Now, there are some not-so-obvious things here that could cause the population not to work that might be confusing here.

    First, right-click on the toolbox and chose "Show All" to see if you're really not getting items populated, or if they're just not there because they're disabled.

    1) If the component class is not marked as public, you won't see the toolbox items when you're on designers for other projects.  By default, when you add a new UserControl (in C# at least), it's internal by default.  So you won't see that toolbox item available on other project's designers, ever.  And, of course, you'll never see a toolbox item as available on the object that it represents (e.g. you can't drop UserControl1 on UserControl1).

    2) EXE projects can not surface user controls to other projects.  So if you add a UserControl to a Windows Application project, you'll see it available to other Forms/UserControls within the project but never outside it.  This is because the project system doesn't support EXE references, only DLL ones.

    Please take a quick look and see if either of these conditions are causing your issue, and if not, help me reproduce it so we can get a bug logged on it.

    Thanks,

    Shawn Burke
    Development Manager
    Windows Forms Team
    Thursday, November 10, 2005 8:40 PM
  • Based on your description, it seems that we misunderstand where the problem occurs:

    It's not when you add folders to a project, but to a solution.

    Instead of creating right away a project which creates a solution with the same name by selecting a Windows Forms Project from the templates "New Project" menu, I use to create first a "Blank Solution" from the "Other projects" node in the project category tree.

    On top of that, I create a structure to handle references to source code of course then separated by project types (i.e. client, server, common, frameworks...) and folders for storing documents and I also like to have a Binary subfolder per release version that is just suppose to hold my last valid release for testing and comparison references.

    So, just try to follow my steps from a blank solution and tell me if you get the same issue or not... It's maybe related to my computer...

    I still found a workaround for my case: unloading and reloading the project from the solution explorer seems to make things work again.

    Cordially,

    Amadrias
    Friday, November 11, 2005 3:29 PM
  • Why does the AutoToolbox feature ignore the ToolboxItemAttribute, and use a general purpose ToolboxItem?
    Monday, December 19, 2005 3:27 PM
  •  

    Good question Frank.  The answer is actually it doesn't ignore it (or shouldn't).

    The items that get added to the toolbox are dummy proxy items.  We do this for performance.  To add the "real" items would be a nasty perf issue - it would force loading every assembly in the outputs and every component in it into the AppDomain, on every build.  For large projects this was a nightmare.

    So to avoid that the AutoToolbox stuff looks at the metadata w/o actually loading the assembly/type and creates proxy items based on that.  I assume this is what you are seeing.

    However, when the assembly is loaded into the app domain (e.g. you create some other class from it on the designer, etc), we detect that and load the "real" items.  In any case when you actually drop an item onto the design surface, we'll call the CreateComponents method of the custom ToolboxItem to do the work.

    The original design was to swap in these "real" items once this on-demand loading happened, but unfortunately the toolbox itself isn't really designed for it.  There's no way to add and remove a particular item or to just update it.  So the updating would cause horrible flashing on the toolbox and/or items moving around all the time.

    So you won't get the bitmap you're looking for (I tried, believe me), but you should get the functionality.

    Monday, December 19, 2005 6:47 PM
  • Our designer cannot accept these ToolboxItems, it expects the type defined in ToolboxItemAttribute. So actually these items are useless for us and confusing for the user.
    Monday, December 19, 2005 8:39 PM
  • I see - sorry about that.

    So you can either filter them out or change your designer's heuristic so that it works off of filters instead of identifying by type.

    In either case, unfortuantely it'll require a change to your designer's metadata so that those items won't show up.

    Basically, to your root component you should add

    [ToolboxItemFilter("SomeString", ToolboxItemFilterType.Require)]

    And to your components base class add:

    [ToolboxItemFilter("SomeString")]

    This should have the effect of hiding the auto-toolbox items since they won't have the right filter on them.

    Hope that helps.


    SB

    Monday, December 19, 2005 8:59 PM
  • Thanks Shawn! I thought they would already be filtered, but I will investigate. I don't remember why we had to derive from ToolboxItem but it was an issue we could not avoid.
    Tuesday, December 20, 2005 3:15 AM
  • Here is some more information about our problem with the service:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=191536

    Thursday, January 05, 2006 9:32 PM
  • Any progress on this? My whole team is experiencing this issue for our project and I think we fit the criteria described above. We started from a blank solution and added in some cases exsiting projects that were dispersed in different sub folders.
    Wednesday, March 01, 2006 9:53 PM
  • I received a response from Microsoft the other day and here is the feedback:

    http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=5c8a598e-b6c7-4a20-90df-d8b6d00284e0

    So wait and see for the next Service Pack.

    Thursday, March 02, 2006 10:05 AM