t Data Type.
Another interesting aspect of tags is that the Tags collection is one of the rare pieces of the Publisher object model that doesn't have a counterpart in the application's user interface. Tags are a totally programmatic feature: you can only access Tag objects through code. Unless you explicitly create an interface to expose them, such as by displaying them in a dialog box, or the user writes code to find them, end users aren't going to be aware of them at all. Which makes them an ideal place to store information you need to persist to perform programmatic tasks, but that you don't want the average, that is, non-programming, user to have easy access to.
Tags are particularly useful for storing the following general types of information:
- Publication, page, or shape attribute information that isn't already persisted in any of the available object model properties
- Variable data that is needed for running some procedure or programmatic functionality
To add a Tag object, use the Tags.Add method, which takes the Tag object name and value as parameters. The following line of code adds a Tag object named CreationDate, with a value of the current date, to the active document:
ActiveDocument.Tags.Add "CreationDate", CStr(Now)
Each Tag object has a Name and Value property. The Name property is read-only and must be unique within a given Tags collection. For example, you can't have two Tag objects named "Creation Date" in a single Shape object, but you can have multiple Shape objects that each have a single Tag object named that.
As mentioned earlier, the Value property takes a Variant data type, which means it can store any data type except fixed-length strings.
ActiveDocument.Tags("Creation Date").Value = "Today"
To remove a Tag object, simply call its Delete method:
As you can tell, adding tags and setting their values is fairly simple. So the question isn't really how to use tags, but what to use them for. What information should you store in tags? For the most part, your business processes determine the answer to that. What information do you need to persist in a publication to complete your business tasks?
Let's take a look at a few simple examples to get you thinking about how tags can work for you.
Suppose you create a catalog of your products, including prices that are subject to change over time. You print the catalog on a desktop printer. However, you want to be sure your employees don't print the catalog for a customer once it's more than three months old. So when you finish creating the catalog, you add a document tag, called Expiration Date, and set its value to a date 90 days in the future:
ActiveDocument.Tags.Add "ExpirationDate", CStr(Now + 90)
Then, you write an event handler for opening the document. The event handler compares the value of the Expiration Date tag with the current date. If the publication is opened after the expiration date, a dialog box displays advising the user not to print the catalog because the prices may not be accurate anymore.
Note For this code to work, place this event handler in the ThisDocument object module for the publication.
Private Sub Document_Open() If CDate(ActiveDocument.Tags("ExpirationDate").Value) < Now Then MsgBox Prompt:="Prices in this catalog may be out of date." & _ vbLf & "Do not release this catalog to a customer" & vbLf & _ "without checking that prices are accurate.", _ Buttons:=vbExclamation, _ Title:="Expiration Date Passed" End If End Sub
Or perhaps you want to classify the publication you create. Suppose you're creating publications for a number of projects. You might want to add a Tag object to each publication to identify which project it's for. So you add a Tag object, named for the project, that has an initial value of "InProcess":
ActiveDocument.Tags.Add "Farble Project", "InProcess"
When the project is done, you change the value to "Complete". Then, you write a procedure that goes through your various work folders once a week and moves any publications where the tag value equals Complete to a "Completed Projects" folder.
Using the FindSha