Drawing Table Parameters to create a Table-of-Contents

[Aaron_Daniel]

Drawings with multiple sheets need a Table of Contents (TOC) - just like any other multi-page document.   Report repeat region parameters would need to be established for just this purpose.  A Table of Contents should be just as easy to implement as a Bill of Materials.  A parametric Table of Contents would update any time a sheet is added, or is re-named or moved in sequence.

[BenLoosli]

Need more information about what benefit this would provide and how you would go about implementing the parameters needed to drive the TOC?

Almost as easy to build a table that can be imported into any drawing and just fill in the cells.

[Aaron_Daniel]

As much as I would like to fully implement Model Based Definition, I've never had a client (in over 30 years) request a project with anything short of a full set of 2D drawings.  For me, multi-sheet drawing packages with a preference for a Table-Of-Contents will be around indefinitely.  Addressing a variety of situations, my average drawing packages vary from 10 to 50 sheets (usually of a custom assembly and the related custom subassemblies and custom parts).  As you indicate - I have to set up a table and manually fill in the cells.  When (every time) sheets are deleted, changed, added... I have to manually edit the TOC table.  In a simple TOC I almost always use the sheet number and sheet name.  On authoritative drawings, the TOC includes the sheet edit date and revision mark, and sometimes a part number and part name.  All of this could be "parametric". 

So, at the very least, a simple TOC would only need to be able to list the sheets (using the sheet numbers as the table index) in a drawing and the drawing sheet name.  With some judicious sheet naming, this makes an effective tool to locate specific details of subassemblies or parts without having to shuffle through the entire Contents of a drawing package. A report index by sheet number, and report parameter of the respective sheet name would be necessary.  Selecting either sheet number or sheet name would 'hyperlink' to the sheet just like the sheet tabs (and be available as 'bookmarks' in an exported drawing).

The implementation of 'edit date', 'revision mark', etc...would mean being able to assign parameters (in addition to the existing sheet name) to each sheet (much like each part having its own parameters in an assembly), and making those available as report parameters.  A multi-sheet drawing can be thought of as an assembly, and the sheets are either sub-assemblies or parts of the assembly.  Additionally, views on each sheet can be thought of as specific features of each assembly or part (just like in the model tree). If sheet parameters could be assigned and made available in table reports (just like parameters of assemblies and parts), this would be an intuitive implementation.  In addition to the preview that the drawing sheet tabs currently provide, they could also provide a toggle to include the sheet in the TOC, and there could be an additional ‘drop-down’ to assign and edit parameters for the sheet (and/or these items could be incorporated into view properties). A parameter would be created in the drawing (or present in the drawing template), that would be designated as unique to each drawing sheet - much like creating a parameter that is included in a part or assembly family table.

In addition, the generation of new view names should be able to be ‘formatted’ to incorporate the view’s model. Instead of ‘new_view_nn’, it should be ‘prt_name’ or ‘asm_name’ and projected ‘prt_name_right’ and ‘asm_name_right’.  Auxiliary views are provided a certain amount of view name formatting in ‘detail options’ with aux_view_note_format (‘VIEW %viewname-%viewname’ by default). New views should have a format option in ‘detail options’ – such as ‘%model_type “-“%model_name’ or ‘%model_parameter“ - “%model_type’.

This would make much more sense in terms of ‘bookmarks’. If you diligently re-name your views, this is potentially how they end up anyway…it’s just a lot of work that could be ‘parametric’.

Ultimately, it would be nice to be able to assign parameters to individual views, and to perform operations within drawings – but that’s another chapter.

And finally…if a view is named to include the name (or the name of a 'combined' state) of the model of that view, then there should be a report parameter of the sheet number(s) associated with that part or assembly within that drawing, so that a BOM that includes that part or assembly can (parametrically) show the sheet number(s) of the view where the part or assembly is located. If a drawing ‘detail option’ of ‘new_view_note_format’ was set to ‘%model_name’_nn by default for the view(s) of a part or assembly, then tracking the sheet(s) where details for that part or assembly is located, would be truly ‘parametric’. Currently, there is an ‘awkward’ and inadequate implementation of report parameters for the drawing sheet and grid location of parts and subassemblies. It’s based on everywhere that a part or subassembly is present – so a multi-sheet drawing of different assemblies, or multiple views of an assembly on different sheets, creates an extensive and impractical list of sheets for a part listed in a BOM.