pesByTag Method
The Document.FindShapesByTag method enables you to identify all shapes in a publication that contain a specific Tag object. The method returns a ShapeRange collection comprised of the shapes from all publication pages that contain a specific Tag object. This includes shapes contained in grouped shapes, as well as shapes on master pages.
The Publisher object model doesn't currently contain any methods to return Document or Page objects that contain specific Tag objects.
For example, suppose you create a book, and each chapter is a separate publication. Within each chapter you use text box shapes for a number of different functions: the main chapter text, but also side-bar stories, pull quotes, figure captions, and so on. Programmatically, there's no way to tell the function of each text box shape. But you can use tags to do exactly that. When you create each publication, add a Tag object to each text box that denotes what you're using it for. For example:
Activedocument.Selection.ShapeRange(1).Tags.Add "StoryType", "PullQuote"
Note The previous code example assigns the tag to the first shape in the ShapeRange you currently have selected in the active document. Obviously, if you only have one shape selected, then that's shape one.
Later, you decide that you want to change the font you used for all the pull quotes, and increase the font's point size while you're at it. You can quickly create a procedure that identifies all the text boxes containing pull quotes, based on the value of their StoryType tag, and makes the appropriate changes.
Note that the Documents collections contains each publication that is currently open on your computer. The following example assumes that you open each publication you want to affect.
Sub FormatPullQoutes() Dim d As Document Dim sr As ShapeRange Dim s As Shape For Each d In Documents Set sr = d.FindShapesByTag("StoryType") For Each s In sr If s.Tags("StoryType").Value = "PullQuote" Then s.TextFrame.TextRange.Font.Name = "Arial" s.TextFrame.TextRange.Font.Size = 20 End If Next s Next d End Sub
Now, let's examine a few more complex examples that use the Publisher catalog merge functionality.
By design, when you perform a catalog merge, the publication pages you create contain no information about the catalog merge publication or data source used to create them. This is true whether you create a new publication, or append the catalog merge results to an existing publication. The publication has no "memory" of being created by the catalog merge process at all. And there are several good reasons, including security issues, why Publisher does not store information about the publication or data source used to perform the merge.
But what if there are instances where you want to persist this information in the catalog publication? The next two code examples use tags to store this information; the first scenario involves merging repeatedly to an existing publication, while the second involves creating a catalog publication.
Note The following examples assume you are familiar with the catalog merge functionality in Publisher 2003. For more information on programmatically executing catalog merges, see Creating Catalogs with Microsoft Office Publisher 2003.
Scenario: Using Publisher Tags to Track Multiple Catalog Merges into a Single Document
Suppose you want to build a single publication as a catalog, and you use several different catalog merge areas and/or data sources. Perhaps each section of your catalog uses a different data source, or each section has a different layout and so uses a different catalog merge area. Because of the complexity of the merge, you want to know which pages in the publication where created with which data sources and publications, and when they were created.
The following code example shows how you could use page-level tags to store this information.
First, the example opens the specified publication and records how many pages are in the publication prior to executing the merge. Then the code executes the merge, appending the resulting pages to the specified