The DocProject 1.9.0 Release Candidate will contain several bug fixes and some exciting new features (well, exciting to me anyway :). In this blog post I'm going to describe some of the new features and show a few screen shots, like usual.
Miscellaneous Features and Bug Fixes
For the sake of time and keeping this blog post short (well, shorter than I could make it), I'm going to first list a few of the important features that I feel deserve to be mentioned, even if I'm not going to elaborate:
- The time it takes to generate the DocSite's full-text search index has been greatly reduced - to the point where it should actually be useable now. In my testing, no more than 10 minutes for over 10 000 topics on a regular desktop computer. I still plan to improve performance even more though and will develop that SqlSearchProvider very soon.
- The DaveSexton.DocProject.DocSites library no longer requires full trust.
- DocSites now have Save, Print, Email and Bookmark buttons in the Contents bar to act on the selected topic. The Print and Email buttons work in IE6, IE7, Firefox and Opera. The Save and Bookmark buttons only work (and are only visible) in IE6 and IE7.
- Build Process Components can now use more of DocProject's API, including the use of cross-AppDomain delegates and event handlers and they are even able to insert dynamic build steps that are actually build steps. I'd like to blog about this separately though.
- The Sandcastle plug-in now uses the ChmBuilder program to generate the supporting Help 1.x files. Localization has not actually been implemented yet, though I plan to address that soon.
- The Topic Designer (shared content) dialog now displays all of the files that have Content/<item> semantics, and they are listed as Content Documents (this includes documents in Shared\Content\ as well). Selecting a document will automatically list all of its items underneath, and from their the dialog works the same as usual when an item is selected. By default, shared_content.xml and header are selected, like usual.
- Bug fixes galore. (Though, it was more bugs due to major refactoring in this release than existing bugs from previously releases :)
And now for some elaboration...
API Topic Management Dialog
Lots of new stuff and refactored code here. I'm not really sure where to begin, so I guess I'll just start off by saying that the API Topic Management dialog now saves its last location and size, and the position of the splitters (and so does the Topic Designer). Now, let's continue on with some of the more obvious and important changes.
Figure 1: API Topic Management Dialog - Tree View and Regular Expression Topic Filter
Tree View
As you can see from the image above, the tree now shows general topics that are defined by the presentation style's doc model (e.g., All Members, Methods, Fields, Properties, etc.). Theses types of topics cannot be filtered with the checkbox; however, uncheck them and all child nodes will be unchecked automatically.
You may also notice in the image that the icons are now synchronized to the API access levels of each topic. For example, in the image above, AI.Cells.Enzyme.acids is a private field, which has an icon with a lock. The tool tip will also indicate that the topic is a "Private Field".
The +/- button above the tree will, when clicked, collapse all nodes if any one is currently expanded, and will expand all nodes if they are all collapsed. There are other buttons that are currently hidden because they have to do with conceptual topics. More on that later...
It's probably also worth noting that the performance of the tree when loading data and finding/applying topic filters has been improved.
Topic Filters
Figure 1 also depicts the improved Topic Filters tab and some of its new features. But let's just start with the basics...
Regular Expression Filter
The options for the Regex filter are now displayed as checkboxes, simply for convenience since there is now more room in the GUI due to the filter types having their own individual tabs. Also, the pattern can now be entered as multi-line, although since new lines will not match any topic names, entering multiple lines (to improve readability of your patterns) will cause the Ignore Pattern White Space option to be checked automatically.
Categories Filter
The categorical filter has also been improved, for performance and functionality. It now supports filtering by API access levels, in addition to API category types. For example, you can now filter by protected fields, or private interfaces and structures.
Figure 2: API Topic Management Dialog - Categories Filter
If nothing is checked under Accessibility then it is simply not taken into account when matching. In other words, any access type is a match - the same as if all access types are checked.
You can also choose an access level without choosing an API type and it will match all APIs with the selected access level. Choosing more than one access level is an OR operation, just like with API types.
To match protected internal members you must check protected and internal since it's treated as a distinct access type. In other words, DocProject does not treat protected internal members as just being protected, or internal. One caveat is that searching for protected internal members will also explicitly match protected-only and internal-only members as well.
Saved Filters
Saved filters are a new addition in 1.9.0. It allows you to save Regex and Category filters so they can be loaded and applied quickly in the future or, more importantly, applied automatically during each build.
Figure 3: API Topic Management Dialog - Saved Filters
You can get filters into the list by clicking the Save button that appears on each of the filter tabs (see Figures 1 and 2). Alternatively, you can directly edit the XML file in which they are saved, located at Help\dynamicFilters.xml. The file does not exist until you add a filter using the dialog and then click OK, but you can create the file yourself if you want (see Figure 4 below).
You can also import filters from a Dynamic Filters XML file using the Import... button (see Figure 4 below). Imported filters are appended to the list and do not replace any existing filters.
Memo is a place to comment on filters. You can edit the memo directly in the grid after you save a filter and it will be persisted along with the filter list when you save the changes to the API Topic Management dialog.
Clicking a Load button will simply load the corresponding filter into the appropriate filter tab (i.e., Regular Expression or Categories) and will then show the tab and apply the value of the Include column to the Include matching topics Search Option. The filter will not be applied, however.
The Apply button will immediately apply the filter to the tree using the current Search Options and the value in the Include column, but will not load the filter first.
You can delete the selected filter by pressing Delete on the keyboard or by clicking the delete button (with the red X).
The arrows are used to order the filters, which is important because all filters that have a check mark in the Build column are applied in order, top-down, during a help build. The Apply all filters during builds option will either check or uncheck the Build column for all filters so that they have the same value as the option and each other. The Apply All button will apply all filters to the tree view immediately, top-down, but without regard to the Build column.
The Include column indicates whether matching topics are included or excluded, just like the Include matching topics Search Option.
These features together provide a powerful way to filter topics. For example, in Figure 3 above the 3rd filter excludes all private fields, but then the 4th filter ensures that one private field in particular, acids is included again since the Include column is checked. The 4th filter will be applied after the 3rd filter, since it appears after the 3rd filter in the list, so the acids field will end up being included after all filters have been processed on that topic.
The schema of the XML file that stores the filters is simple, so I'll just give an example file that was created from the filters in Figure 3:
<?xml version="1.0" encoding="utf-8"?>
<filters>
<filter type="DaveSexton.DocProject.Sandcastle.TopicManagement.RegexTopicFilter">
<include>False</include>
<pattern>Carbon$</pattern>
<memo>Get rid of any topic that ends with "Carbon".</memo>
</filter>
<filter type="DaveSexton.DocProject.Sandcastle.TopicManagement.RegexTopicFilter">
<include>False</include>
<options>IgnoreCase</options>
<pattern>^Startup$</pattern>
<memo>Get rid of the Startup classes in each assembly.</memo>
</filter>
<filter type="DaveSexton.DocProject.Sandcastle.TopicManagement.CategoryTopicFilter">
<include>False</include>
<memo>No private fields.</memo>
<types>Field</types>
<access>Private</access>
</filter>
<filter type="DaveSexton.DocProject.Sandcastle.TopicManagement.RegexTopicFilter">
<include>True</include>
<pattern>^acids$</pattern>
<memo>Reinclude the "acids" field, even though it's private.</memo>
</filter>
</filters>
Figure 4: Example Help\dynamicFilters.xml file
Note that the type attribute will accept assembly-qualified type names so that you can define your own custom filters; however, I've not actually tested custom filter types yet so they may not actually work, but I plan to support them in a subsequent release.
The element names for a filter's options are defined by the filter itself, although memo, include and build (which is not shown in the example because it defaults to True) are built-in to the base type because they have special meaning to DocProject.
XML Documentation
In 1.9.0 there are some new features to help make authoring documentation easier. But before I begin on that, I'd like to lead in with some info about where DocProject currently stands on handling conceptual content since it has had a profound effect on 1.9.0.
Conceptual Content
The next release of Sandcastle might be available on Monday (the 29th of October), and you can probably expect DocProject's release to follow within a few days. One thing that I'm really excited about is that the Sandcastle team will be shipping their internal conceptual configuration file for the Build Assembler program, which should allow me to enable the long awaited first-class support for conceptual content in DocProject. If I can include support in 1.9.0 without too much delay then I certainly will, but if that's not the case then expect it in 1.10.0.
The Tree View and XML Documentation
In preparation for conceptual content, I've refactored the code some more and made some assumptions about how the process will be integrated. Also, I've included my new XmlTreeView control with DocProject 1.9.0 RC (it's being used in the API Topic Management dialog now). It supports drag/drop to reorder nodes (to be used for conceptual content only, once it's supported) and to drag nodes onto the XML documentation editor, which automatically creates a <see> link (that is supported in 1.9.0). Also, the XML documentation editor now applies the style sheets of the selected presentation and a special designer style sheet that you can edit yourself: Help\Styles\TopicDesigner.css. The designer sheet formats XML documentation markup such as <c> and <see> tags. All of the style sheets are used in both the Topic Management and Topic Designer (shared content) dialogs.
Figure 5: API Topic Management Dialog - Xml Comments
The list of XML documentation sections is now generated automatically from DocProject's configuration file based on the type of topic that is selected. Then the list is also merged with the actual elements found in the external XML documentation files, which allows users to add custom elements to external XML documentation files outside of the API Topic Management dialog and then use the dialog later to edit them. There are other ways to manage custom elements, which I'll discuss later.
Figure 6: API Topic Management - Xml Comments Sections
The parameter that is selected in the image above was added by DocProject based on the reflection information that was provided by Sandcastle. The method in the example only has one parameter, but if it had multiple parameters then there would be one param name="value" item in the list for each.
BTW, I just noticed a regression: the GenericClass should not show the back tick in its name - I'll fix that :)
You cannot delete delegate/method parameters or generic type parameters from the list. You also cannot delete sections that may only appear once, such as summary or remarks. But you can delete custom sections and sections that may appear multiple times, such as exception and permission, by right-mouse clicking and selecting Delete from the context menu.
To add an instance of a built-in section that may appear multiple times, you can select one from the drop-down list at the bottom. The list displays only those items that are related to the API type of the selected topic. You can also add custom sections by simply entering the name into the combo box and pressing Enter on the keyboard.
When a custom item is selected the attribute grid, which is displayed above the XML documentation editor, is completely editable, except for the Type column. (Although I may change that - I haven't decided yet.)
You can create more built-in sections easily by registering them in DocProject's configuration file (commonly found at, C:\Program Files\Dave Sexton\DocProject\DaveSexton.DocProject.dll.config) under the sections element:
Figure 7: documentationTags element in the DocProject configuration file
XML documentation tag usage data has been retrieved from the following sources:
- Recommended Tags for Documentation Comments (C# Programming Guide)
http://msdn2.microsoft.com/en-us/library/5ast78ax(VS.80).aspx
- The "Tag Matrix" that is present in Dynicity LLC's XML Documentation Comments Guide:
http://www.dynicity.com/Products/XMLDocComments.aspx
(Note: There are differences between the config data and the published matrix due to bug fixes and/or differences in versioning and tag/aspect applicability.)
Conclusion
There's much more, but I have to go catch a train now...