This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

  • Article

Build an Easy Maintenance Intranet Site: Using Office Docs, File System Object, and OLE Structured Storage
Josef Finsel
This article assumes you're familiar with Visual Basic and VBScript
Level of Difficulty   1    2    3  
Code for this article: Finsel0300.exe (32KB)
SUMMARY If you've ever needed to build an easy-to-maintain intranet site, here's a solution based on Microsoft Office documents. Many sites require constant updating of their HTML, but the use of Word documents can simplify the process. This article details the construction of a human resources site that exploits the File System Object (FSO), OLE Structured Storage, and ActiveX capabilities of Word documents. This allows the HR staff to copy their revised or newly created Word files to the site, dynamically generate a list of links to their files, and free IS from the constant recoding of HR updates into new HTML pages.

W

hen scripting languages like VBScript and JScript® were introduced several years ago, they were specifically designed to operate in a sandbox. To reduce the chance of virus damage spread through embedded scripts, these languages specifically excluded the ability to perform file operations. This worked wellâ€"at least while scripts were primarily contained on the client.
      The introduction of Active Server Pages (ASP) has brought with it an increasing interest in server-side scripting. This, in turn, has led to a need for a good method of file access from within server scripts from known sources. Since VBScript and JScript don't support file operations, the File System Object (FSO) was designed to provide these functions to ASP developers.
      The FSO object model provides an object-based tool for working with folders and files. You can use the familiar object.method syntax with the FSO's rich set of properties, methods, and events to process folders and files.
      The FSO object modelâ€"incorporated into the Scripting type library (scrrun.dll)â€"wraps all of the functionality found in the Visual Basic Drive, Folder, and File objects with a more cohesive interface, making it easier to create, alter, move, and delete folders, and detect whether a particular folders exist and where you can find it. The object model also lets you gather information about folders such as their names, the date they were created or last modified, and so forth.
      In this article, I'll demonstrate how to use the FileSystemObject component and OLE Structured Storage to build a Human Resources intranet site that displays Microsoft Word and other Office documents in just a few easy steps. But first, let's look at the hard way to do it.

An Old-fashioned Solution


      Suppose your boss shows up one day with a project. You need to put your company's policies and procedures on the corporate intranet. The bad news is that you have a thick binder of documents. The good news is that all the policies are already available in Word format, so they don't have to be retyped.
      An obvious choice would be to fire up Word and start opening documents and saving them as HTML, making notes as you go about which file names have which policy and procedure titles associated with them. The HTML formatting all looks okay, so you assume it's all going fine.
      The next morning you build a table of links to all of the converted files, with a hyperlink in one column and a title in the next. After spending a few days on this project, adding and deleting columns from your table, you're nearly finishedâ€"but not quite. After all, Human Resources documents change from time to time. What you've really done is bought yourself the permanent, ongoing task of converting each new document as it's written.

A Better Plan


      Having encountered similar situations in the past, I knew there had to be a better way. Take the Word documents, for instance. Their design is based on the ActiveX® document specification. When you attempt to load a Word document from within Microsoft® Internet Explorer, the browser invokes a copy of Microsoft Word as an ActiveX server, integrating the menus for Internet Explorer and Word and loading the document within the browser window. If you are using frames on your Web site and point to a Word document, the browser will load the document within the specified frame. Even if all employees don't have Word installed on their computers, Microsoft offers a free viewer for Word documents (https://office.microsoft.com/assistance/9798/viewerscvt.aspx) that can be installed easily. So that's one problem solved. Users can view the properly formatted document directly from an intranet site without the intermediate step of converting it to HTML.
      But how does the file get on the site in the first place? After all, you don't want the Human Resources director sending you Word documents to put in a directory any more than you want to convert those documents to HTML. This is actually the easiest problem to solve. Microsoft Internet Information Services (IIS) uses physical directories on the Windows NT®-based server as virtual sites and directories.
      Using this functionality, it's quite simple to let the Human Resources department publish their own documents. Simply set up the Human Resources policy site in a virtual root, then share the corresponding physical directory to the Human Resources department. If the server is a part of your domain, you can even let Human Resources use their current logins and passwords. If not, the administrator of the server will need to maintain the Human Resources user IDs and passwords, or set up a trusted connection. Once the share is in place, map a drive for whoever will use it and they'll be able to copy their files to the Web server, keeping you from having to get involved with that aspect as well.
      That solves two problems. You no longer have to format the policy documents, and you no longer have to put them on the Web server. But how can you automatically generate a new table to list the available files? Again, there's a hard way and an easy way.
      You could build a small database and give Human Resources a way to update it whenever they introduce a file to the system. That would involve designing an interface program that would let them access and update the information. But what happens when they just stop using the database and the file list gets out of sync? You're called back into the project because it's not working, even though it's a user problem.

Plan C


      Another option is to use a mix of several technologies to generate this table without user intervention. This recipe calls for one part OLE, one part FSO, and one part ASP.
      OLE 2 uses a technology called OLE Structured Storage. I didn't know what that was, even though I'd been using it for years. The simplest explanation is that OLE 2 is a file system within a file. Structured Storage lets you store extra information within a file in an easily retrievable format. See the sidebar "OLE Structured Storage" for more information.
Figure 1 File Properties in Word
Figure 1File Properties in Word

      For years I've used the file properties in Word to store information about the files I generate (see Figure 1). When I was first looking for an easy way to put Word documents on an intranet, my thoughts turned to this file properties dialog. If there were a way to read the file properties, I could just pull in this information when I wanted to create a list of files, then write an ASP page to read this information, format it, and provide links to the documents.
      This was easier said than done, however. I started searching for the easiest way to access this information, and quickly struck paydirt on MSDNâ„¢. To begin with, I learned about OLE Structured Storage and how it works. According to Microsoft, access to COM Structured Storage is through a set of APIs, and for more information you should check out the Platform SDK or search MSDN on Structured Storage.
      The problem with these APIs is that they're not Automation-compatible, and they can't be accessed directly from Visual Basic® or scripting code. Fortunately, I also found DSOFILE, an in-process ActiveX DLL that allows you to read the file properties for any OLE Structured Storage file. DSOFILE was written specifically to give programmers using Visual Basic access to this data. Once I had downloaded a copy of DSOFILE (https://support.microsoft.com/support/kb/articles/Q224/3/51.ASP), I was almost ready.
      The last thing I needed was a way to walk the directory of files. For that I turned to the FSO, a simple interface to the file system that's available with IIS and Internet Explorer 4.0 or higher.
      First, you should download and run the DSOFILE component. This is a self-extracting ZIP file that contains a copy of DSOFILE.DLL as well as some sample code. Second, place a copy of the DLL in your Windows® System32 subdirectory, then run

 

regsrv32 dsofile.dll

to register it.
      Next, create a virtual Web root and open a new ASP document in it. Set your server-side scripting to VBScript:

 

<%@ Language=VBScript %>

Open up a script block so you can create the necessary objects: a file system object, a folder object, and a file object that will give you access to the files you'll be looking at. These are all accessible through the FileSystemObject component:

 

dim objFSO               ' File System Object
dim objFile              ' File Object
dim objFolder            ' Folder Object
set objFSO = createobject("Scripting.FileSystemObject")

      A property reader object and file property object will give you access to the OLE Structured Storage:

 

dim objPropReader   ' Property Reading object
dim objFileProps    ' Object that stores the file properties
Set objPropReader = CreateObject("DSOLEFILE.PropertyReader")

      Finally, you need a string to store the physical path pointed to by the Web site:

 

dim sMapPath            ' String to store the Real Path

      Since you need to know the directory in which to begin, use the Server variable MapPath to get the real location of the Web site and store that in sMapPath. With this location saved, you can instantiate a folder and walk through the files in the folder with a for each...next loop.
      With each file, you should attempt to get its OLE Structured Storage properties:

 

set objFileProps=
    objPropReader.GetDocumentProperties(objfile.path)

Since there is no way to tell if the file uses OLE Structured Storage, you should try it and check to see whether the attempt creates an error. If no error is reported, then you can build the next row of your table. The table contains a title, file size, date last modified, and description. If the file has a title defined, it's displayed; if it doesn't, the actual file name is shown.

 

<TD width="25%">
<A HREF="<%=objFile.Name%>"><%
    if trim(objFileProps.Title) = "" then
        Response.Write objFile.Name
    else
        Response.Write trim(objFileProps.Title)
    end if%>
</A></TD>

      Next, format the file size and date last modified as retrieved from the file object:

 

<TD>
if objFile.size < 10240 then
    Response.Write objFile.size & " Bytes"
elseif objFile.size < 1048576 then
    Response.Write round(objFile.size/1024,1) & "KB"
else
    Response.Write round((objFile.size/1024)/1024,1) & "MB"
end if
</TD>

<TD><%=objFile.DateLastModified %></TD>

Last, but not least, put the file comments out there:

 

<TD width="*">  <%=objFileProps.Comments%> </TD>

The complete code for this intranet site is shown in Figure 2.

Conclusion


      With these simple steps, you now have an intranet site that can be administered by the Human Resources department without any intervention on your behalf. They can add and delete files and change the wording in the table however and whenever they want. In addition, this is a reusable component, available to any IIS-based Web site your company may want to create. I strongly suggest you use FSO and Structured Storage attributes whenever you want to use Office-based files on an intranet. It's easy, complete, and a great time saver.

For related articles see:
https://msdn.microsoft.com/library/devprods/vs6/vbasic/vbcon98/vbconprogramminginfsoobjectmodel.htm
and
Background information: try
Understanding ActiveX and OLE (Microsoft Press), https://mspress.microsoft.com/books/901.htm

Josef Finsel is a consultant with Rapidigm, specializing in developing intranet and Internet solutions that use Microsoft products. He can be reached at https://www.finsel.com.

From the March 2000 issue of MSDN Magazine.