Office 2003 is being released this month, and a cast of supporting
applications is already available. One of these is Windows
SharePoint Services 2.0, the free team add-on for Windows Server 2003.
If you’re not familiar with SharePoint Services basics, take a look at What Developers
Need to Know About Windows SharePoint Services. In this article, I’m
going to drill into one key place where SharePoint and Office 2003 overlap:
Introducing Document Workspaces
Figure 1 shows a typical document workspace, in this case using Excel 2003
(the document workspace feature works with Word, Excel, and PowerPoint in this
version of Office). The workspace is built around an Excel document. The task
pane at the right hand side of the screen contains the collaborative content,
including members, tasks, files, and hyperlinks.
The Shared Workspace task pane lets users interact with all of the shared
content. For example, they can add new tasks, schedule meetings, or link
additional documents to the workspace. But as a developer, you’d probably prefer
a more programmatic way to control workspaces. For example, suppose you could
automatically generate a list of the open tasks in a workspace? Fortunately,
this being Office, that’s entirely possible. Like nearly every other part of
Office, workspaces are available through an object model.
The Shared Workspace Object Model
Figure 2 shows the object model for shared workspaces. This object model is
consistent across all of the workspace hosts (Word, Excel, and PowerPoint). As
you can see, it’s fairly simple: there’s a top-level SharedWorkspace object that
can be reached from the object representing each individual application. Below
that top-level object are other collections and objects that represent the
contents of the workspace.
If you understand VBA, using these objects is easy. For example, here’s a
tiny piece of code that you can run as a macro to list out some information
about shared workspace tasks in the current document:
Public Sub ListTasks() ' Retrieve the object root Dim sws As SharedWorkspace Set sws = Me.SharedWorkspace ' Iterate through all tasks Dim swt As SharedWorkspaceTask For Each swt In sws.Tasks ' Print out some information Debug.Print swt.Title Debug.Print swt.DueDate Debug.Print swt.AssignedTo Next swt End Sub
If you run this code as a macro, and there are actually shared tasks, you’ll
get information on each one:
Order Louisiana Hot Spiced Okra 10/29/2003 Mike Gunderloy Customer Followup Call 10/2/2004 Nancy Davolio Pack and ship order 9/27/2003 Margaret Peacock
Of course, in a production application you’d also want to avoid errors. One
way to see whether the current document is part of a shared workspace is to
check the value of the SharedWorkspace.Connected property. If this property
returns True, then the rest of the shared workspace objects will be
Creating Objects in a Workspace
One good use for the shared workspace object model is to inject new objects
into a workspace programmatically. For example, you might want to automatically
add updated files to a file library from a batch process that runs overnight, or
assign tasks based on some external input. Here’s a bit of code to add a new
task to a workspace:
Public Sub AddNewTask() ' Retrieve the object root Dim sws As SharedWorkspace Set sws = Me.SharedWorkspace ' Add a new task sws.Tasks.Add "Check Receipt", _ msoSharedWorkspaceTaskStatusNotStarted, _ msoSharedWorkspaceTaskPriorityNormal End Sub
Each of the collections in the shared workspace has its own Add method,
though each takes different parameters. For example, when adding a task, you can
specify any of these parameters (only the task name is required):
- Task Name
- Date due
Note that the object model supplies constants for arguments such as Status
and Priority, which are limited to a fixed number of values.
The Collection Interface
Each of the collections in the shared workspace (SharedWorkspaceTasks,
SharedWorkspaceLinks, and so on) supports five members. You’ve already seen the
Add method. Two other members are standards that you probably expect on any
Office VBA collection: Count (to retrieve the number of items in the collection)
and Item (the enumerator for the collection). Each collection also has a
Parent property that points to the containing SharedWorkspace object.
The last property of each collection is the ItemCountExceeded property. It
turns out that there’s a user interface limitation to the Document Workspace
task pane: it can only display 99 members, tasks, documents, or links. When one
of the collections grows so large that it cannot be displayed, the
ItemCountExceeded property will return True.
What about removing an item? This is a method, not of the collection, but of
the individual item. For example, you could remove the first task in a workspace
with this bit of code:
Public Sub RemoveFirstTask() ' Retrieve the object root Dim sws As SharedWorkspace Set sws = Me.SharedWorkspace ' Remove the first task sws.Tasks(1).Delete End Sub
Note that the collections in the shared workspace object model are
With this bit of basic knowledge, you should be able to start seeing how to
leverage document workspaces in your own custom Office 2003 applications. For
example, do you work with Office documents as part of a workflow application?
Perhaps right now your application e-mails people with a list of jobs that they
need to perform in order to move things along. With the new capabilities, you
could instead create a document workspace containing the document, add the jobs
as custom tasks, and send a simple link to the document. As soon as they open it
up in Word or Excel, they’ll see their assigned tasks right there.
This is just one facet of a major push in Office 2003, which I think of as
programmable collaboration. The major applications within Office have been
suitable for serious work with standalone documents for several versions now.
Office 2003 adds tighter integration with SharePoint, Outlook, and Exchange, as
well as other products like Communications Server, to move us forward to a
vision of working with a complexly-interlinked network of documents and users.
It will be interesting to see how well this can be exploited by developers to
build new applications on top of Office.
Mike Gunderloy is the author of over 20 books and numerous articles on
development topics, and the lead developer for Larkware. Check out his MCAD 70-305, MCAD
70-306, and MCAD 70-310 Training Guides from Que Publishing. When he’s not
writing code, Mike putters in the garden on his farm in eastern Washington