We intentionally left it out of the item template, actually.  The reason being that, in reporting scnearios, you can end up with so many custom BBSs that it would put a whole new meaning to "blue cog of death" if they were all flagged to show up in the toolbox . 

We create and manage the custom BBSs in code, which we find cleaner (and less blue coggy), but you can always make your own template based off of our standard BBS item template and modify it to include the toolbox attribute.

Understand and it is reasonable, but then there must be something I am missing, for example to design the reports, I drop a ReportManager into the form where the report will be called, then I drop an instance of the reports BBS in the same form, so I can create the report's Data Sources and design the report, is there any other way to do this that would not required all my report's BBS to have the ToolBox attribute?

Please see the attached image.

Edhy Rijo

This is about to become a really long post if I try and explain a different way to do this.  You can do it the way that you are going at it just fine without issue.  But there are two things that we do here.  First, we actually program with the AutoPopulateToolboxWindow set to False so in this casn we just open up the designer file and add the BBS manually (we do the same for BOs) since the toolbox population can take longer and longer the more than you have.  That is the easy part of this explanation.

The long drawn out part is what we actually do in our medical software.  We actually design all of our reports at run-time after we have designed the data sources, etc.  This allows us to change and create reports in the field.  In this case, we define the data sources, and then they become available as a data source selection at run-time.  So all of our reports are stored in a database instead of in a code file.  Now the BBSs, data sources, report criteria forms, etc. are all in code, obviously.  But the actual report itself is data stored and driven.

You can see all of the reports available here in our report designer.  I can add a new report, template, etc.  all through the run-time interface.  When I create a report, I can then select the report and set the data source:

This is a BBS that gets associated with the report when run.  So in this case, when we open the designer within the template we create and expose the data sources to the Report Sharp-Shooter report and design controls so that they can be accessed and referenced just as though they were dropped on a form.

Within the designer, you can see all of the elements associated with the data source and just drag and drop them onto the report:

Finally, before the question comes up, we really cannot give this to you or pre-plumb this as it is really specific to our medical application and our needs.  Most likely, you do not need anything this elaborate so it would be overkill for most developers.  However, we have very complex and specific needs so we had to take this approach so that it allows our users to copy over the default templates and change every report in the application.  Also, for us to provide this as an app or module to purchase like RBS, it would get really complex and muddy as this is part application, but also part customized.  So it is really entrenched into our medical app.  But this should at least help you understand Dustin's comment and understand how to take a different data driven approach if you have this need.

Darn, I knew you would say something like that .

Seriously, thanks, it does explain many things, and you are right, that kind of flexibility is not always needed by the end user.  So in my case it would be safe to do one of the following:

1. Design reports as I am doing, in the form where they will be called, and then remove the reports BBS from this form and the toolbox attributes since once the report is complete, they would not be used unless I need to add or change a field?
2. Or, could I create a ReportManager subclass in a temporary form used to just create all reports, then in each forms where the reports would be used, create an instance of that ReportManager subclass to use the report?

If number 2 can be done, I would prefer that path, since I notice that in the ReportManager you can have many reports and many Data Sources to assign to those reports, this way, I would have some sort of centralization at least to create the reports.

Edhy Rijo

You could do your #2 option, but the only thing I would caution on this one could be size and sluggishness of you get a lot of reports.  In our medical application, we will have over 200 reports.  This on a single form would kill it, but if you are only going to have a couple of dozen, then it wouldn't be that big of a deal.  Even if you go with option #2 and run into performance issues at design-time (or run-time), it shoulnd't be too difficult to break it apart if you had to.