SharePoint Development from a Documentation Perspective
So, after blogging several times about the Tags functionality in Publisher, I finally took a look in the PowerPoint object model, and guess what I found? However, the tags functionality is implemented a little differently in PowerPoint than in Publisher, so it deserves some discussion.
To review: Tags are, in essence, generic holding bins where you can store whatever information you want to persist with the presentation. Each tag is comprised of a name, and a value. Tags are one of the rare pieces of the PowerPoint object model that doesn't have a counterpart in the application's user interface. Tags are a totally programmatic feature: you can't get or set Tags objects except through code. So unless you explicitly expose them in the user interface (by displaying them in a dialog box, for example) or the user writes code to find them, the average user isn't going to be aware of them at all. Which makes them an ideal place to store information you don't want the average (that is, non-programming) user to have easy access to, such as:
· Attribute information that isn’t already persisted in any of the available object model properties.
· Variable data needed for programmatic functionality you’ve written.
In PowerPoint, the Tags object is a child of the Presentation, Slide, SlideRange, Shape, and ShapeRange objects, so you can use it to store custom information at the presentation, slide, or shape level.
Each tag has a name, and a value. In Publisher, the tag value took a Variant data type; in PowerPoint, you’re limited to a String data type for the tag value. The biggest difference between how the two application implement tags, however, is in how you create and access individual tags. Unlike in Publisher, the Tags object in PowerPoint is not a collection; there are no individual Tag objects in the PowerPoint object model. Rather, you get and set the name and value of the individual tags by using methods of the Tags object itself. Here’s how tags are structured in the PowerPoint object model:
As you can see, Name and Value are methods of the Tags object, rather than properties of an individual Tag object (as they are in Publisher). Personally, I find this makes them a little more cumbersome to work with, but the PowerPoint object model has been around a lot longer than the Publisher object model, and the Tags object has been there since at least PowerPoint 2000, so I’m willing to cut it a little slack.
Here’s another aspect of the Tags object that may be less than intuitive: to update the value of a tag, you call the Tags.Add method, passing the name of the existing tag, and the new value. This effectively overwrites the tag and updates the value.
So let’s look at a code example. Here’s one I swiped from the PowerPoint Visual Basic Reference. It tests the value of the Region tag for all slides in the active presentation, and hides any slides that don't pertain to the East Coast (denoted by the value "east").
For Each s In ActivePresentation.Slides
If s.Tags("region") <> "east" Then
s.SlideShowTransition.Hidden = True
As I noted in my entries about tags in Publisher, you can come up with some pretty simple, yet powerful solutions by using tags to store custom information where you need it, then writing procedures that use that information. What kind of information, and what do you use it for? Whatever makes the most sense for your business practices.
Think about it.