Tips for Use of MS Project (e.g. on \\numiwinctr1)


These tips for the use of MS Project will be a mix of tips that either apply to the use of MS Project 98 on any Wintel machine or apply specifically to their use on \\numiwinctr1. The user will (hopefully) be able to distinguish between the two types of tips by their context.

Latest Version of MS Project 98

The latest version of MS Project 98 is SR-1. That Service Release corrected a number of bugs (refer to the Microsoft Knowledge Base, reachable at "", for a list of what was corrected). One can check the version by opening PRJ98, clicking Help, and then clicking on "About MS Project".

Print to PostScript File

Michael Li has created a pseudo-printer that can create a PostScript file. This should compensate for the lack of a "print to file" option when printing--like is available for other Microsoft applications (e.g. MS Word, MS Excel).

For other machines here is a URL which gives instructions on how to set this up.


Here are the steps for applying individual customization of MS Project on \\numiwinctr1. Some or all of these steps may be unnecessary, depending on the history of the user account on \\numiwinctr1.
  1. Use the mouse to highlight the MS Project icon in the Program Manager Window.
  2. Under the "file" menu, choose Properties.
  3. Make sure that the working directory entry is one for which you have write privilege--e.g. your own directory area.
  4. If a change was made, mouse click "ok".
  5. Go to the file manager and copy "\\numiwinctr1\numiuser\Global.mpt" to the working directory just mentioned.

With the above steps in effect, exiting from your next invocation of MS Project will allow you to save your changes to your own copy of "Global.mpt". This should customize your subsequent sessions of MS Project.

I have seen that if my working directory for the MS Project icon is "W:\Office97\PRJ98" and I start MS Project from the File Manager by double clicking on a project file, then MS Project does not use the file "W:\Office97\PRJ98\Global.mpt". It uses some other "Global.mpt"--probably the one it was using before I customized as described above. Because of this I always make it a practice to start MS Project 98 from the Project Manager.

Changing external links

Bruce's MS Project files have numerous external links in them. For example, file "MINOS_2_1.mpp" (the steel file) has external links to "MINOS_dates.mpp". File "MINOS_2_0.mpp" is a master file and has the other project files "embedded" in it (a "project" task for each file). When these files reside on Bruce's laptop, the files have absolute paths that reference his directory structure on that machine. When he copies them to "\\numiwinctr1\numiuser\baller\minos\schedules\Current" they keep the path names from his laptop in the external links.

On \\numiwinctr1 I prefer to work with copies of Bruce's files. I copy the *.mpp files from "\\numiwinctr1\numiuser\baller\minos\schedules\Current" to "w:\wehmann\test", and would like to arrange it so that the external links utilize that path, and therefore the local copies.

A way to do this is to open up my local copy of "MINOS_2_0.mpp", and then try to open up one of the files it has embedded in it (again using the File, Open, menu choice). For example, the choice could be "MINOS_2_1.mpp". MS Project 98 will complain that it can't find the file, so I use the Browse feature to find the file for it. That combination seems to update all the external links to have the path pointing to where the files reside. This is also discussed in Bruce's advice on how to avoid problems.

Cure for Rob's misbehaving file

On 8/28/98 the Near Detector file, "MINOS_2_5.mpp", was crashing PRJ98 on Bruce's laptop. It sort of worked on \\numiwinctr1. Bruce called up Microsoft (one call of a 10 call, $1700 support contract--no charge if your problem isn't solved). Their solution was to have Bruce open up a new file inside PRJ98, embed "MINOS_2_5.mpp" in it, then double-click on the embedded file, use the Advanced tab to say not to Link back to the source project, and then save the file. Some file renaming was obviously necessary. Lost in the process were the external task linkages and the unique task ids.

A later call to Microsoft Support elicited the advice to do the above, but save as an mpx file, close, then open the mpx file. They also advised to keep linked files all in one directory area, to avoid corruption of the files and linkages. That way, all links would have the same path name (Gee, why don't they allow for relative paths?).

File Closure Oddity

With Bruce's files and their external links among each other, the following oddity can be observed. Open up two of the files. Go to the Visual Basic Editor and use the Project Explorer to note that both files are represented there as "projects"--in addition to "Global.mpt". Return to the Project window and close one of the project files. Go back to the Visual Basic Editor. You will probably see that the closed file is still represented in the Project Explorer window. Bruce and I are betting that Projects.Count will still count the file that you closed.

A trial with Excel did not have this behaviour. A trial with two project files not sharing any tasks as external links, did not have this behaviour, either. It probably has some connection with the tasks shared by external links between two project files.

The disappearing/appearing file extension

The following curiosity has been observed. On \\numiwinctr1, with File Manager, the project files have the extension ".mpp". On Bruce's laptop, running Windows 95, the files have no extension in the Explorer window. During execution of the function "ActivateMINOSSheet" in the VBA code in the project file "MINOS_dates.mpp" the extension ".mpp" is present in "Projects(i).Name" in one case and not the other. For this reason, an explicit test had to be made in that function for the presence of the extension; if it is present, the string ".mpp" is appended to "prjname" for the comparison with "Projects(i).Name".

I read somewhere that displaying file extensions is an option with Windows 95 (or Windows NT, I suppose). How exercising that option affects the behaviour discussed above is a mystery to me, since I don't have ready access to such a machine.

Linked Fields

In the project file for the TEC stuff, Nancy Grossman has been creating milestone tasks, and then linking start dates from other tasks to the milestone start date (using Edit, Paste Special, Links). When these links are working, double clicking on the start date field in the milestone task causes the cursor to jump to the linked field (this assumes that the user responded in the affirmitive when opening the file, when asked if active links were desired).

In the TEC project file, a number of these links aren't working (Nancy is slowly repairing them). They still show a small triangle in the start date field, but double-clicking on that field brings up the Task Information window--rather than jumping to the linked field. Nancy says that the jump won't occur if the linked task is "hidden".

One thing these linked fields do is minimize the number of long vertical lines in the Gantt chart--i.e. those showing task linkages due to use of the Predecessor, Successor fields.

If one copies a project file that has such links, opens the copy and replies to the query that one wants the links active, the links will point back to the file that was copied. Experience has been that in this case one will get asked twice if these links are desired, and will get asked twice if one wishes to enable macros. By using the Visual Basic Editor and then invoking "Project Explorer", one can see that both the copy and the original file are open. In fact, one can see the macros from both files.

Large File Size

Dave Pushka noted that the file size on his project file had increased noticeably. It turned out that the keyboard on his NCD terminal was mal-functioning, and he was inadvertently entering task ids in the "predecessor" field that didn't exist; in fact the false task ids were much larger than any of the real task ids. The result was that MS Project 98 would insert a bunch of false rows.

The cure was to use File, Save As, to a different name. The message below, from the microsoft.public.project newsgroup, says something similar.

Subject: Re: Enormous file sizes
Date: 15 Jul 1998 00:00:00 GMT
From: Matt Parks 
Newsgroups: microsoft.public.project
You might have them try doing a Save As. PRJ98 does not actually delete records when you delete a task, resource, etc. The record is kept in the file to speed up saves. If you do a Save As, close the file, re-open the file, and then another Save As, it will get rid of these "Deleted" records. Closing the file in between is important or the "Deleted" records keep getting saved in the new version.

Something else to look for is to see if the user accidently inserted a bunch of tasks into the plan. I had one person come to me for help when her file became about 20 MB for a plan with only 150 tasks. It turned out something got placed on the key on her keyboard. The result was over 40,000 blank tasks inserted and saved in the plan. You can tell if this happens by looking for Task numbers next to blank tasks. Normally, there won't be a number on the left for a blank task. Another way is to see if the scroll bar doesn't reflect what you think is the actual positioning in the plan.

Hope this helps,
Matt Parks
The Revere Group

Bill Miller and Bruce Baller had a similar experience with file size increasing dramatically. In their case they intended to add another id number to a list of existing predecessor ids & they forgot to put in a comma as the separator between the end of the existing list of predecessor ids and the one they were adding. In that case, one "Save As" was sufficient to reduce the size of the file back down to where it belonged.

Unique ID values

You may have noticed that when you open the "MINOS_2_0.mpp" file it has the "MINOS_dates.mpp" and "MINOS_2_1.mpp through MINOS_2_5.mpp" files apparently embedded in it. If you open up one of the "MINOS_2_1.mpp through MINOS_2_5.mpp" files inside of "MINOS_2_0.mpp" you may notice that the Unique ID field is different from when you open up the same file outside of "MINOS_2_0.mpp". This is because an offset is being applied to that field while inside "MINOS_2_0.mpp".


10/7/98, Advice from Bruce

Date: Wed, 07 Oct 1998 11:51:22 -0500 (CDT)
From: Bruce Baller 
Subject: Opening up updated project files


Here is the procedure for opening MS Project files from NUMIWINCTR1 Current folder. This procedure should insulate you from problems with external tasks.

  1. Copy all of the MINOS__2_n files (n=0 to 5) and MINOS_dates to your folder. For the purpose of this example, let's call the folder C:\smith\MINOS\CSP\Current.
  2. Open up MINOS_2_0
  3. Click on the MINOS_dates task expand box ("+" sign inside a small box). This opens up MINOS_dates and Project then attempts to update the external tasks. It will not be able to find C:\MINOS\schedules\Current\MINOS_dates, unless you have put these files in a local folder with the same path. If you do have a local folder called C:\MINOS\schedules\Current with old versions of the schedule Project will connect to the old versions!! Be sure to remove any old files from C:\MINOS\schedules\Current.
  4. Use the Browse command to point Project to C:\smith\MINOS\CSP\Current\MINOS_dates, and click OK. Project should now use this path to open up all MINOS_2_n files.
  5. Open up the MINOS_2_0 window and save. You should select "Yes to all" to save all files with the updated path.
  6. You can now open up MINOS_2_n files individually.
I have CC'd Alan Wehmann with a request that he update his MS Project WWW site with this information.

When going through this procedure with Rob Plunkett this morning, we discovered that some files on NUMIWINCTR1 weren't copied last night because someone had one of the files open. The files are now up to date.

Bruce Baller
Phone	(630) 840-2427
Fax	(630) 840-6039
This topic is also discussed in an item above.

Nov. 20, 1998, Printing PostScript

Tom Chase told me today that he has been sending PostScript files to people and they complain that they can't print them on their PCs. Below is a post to newsgroup "comp.lang.postscript" that suggests how to do it. Other possibilities are Ghostscript and GSView or "SuperPrint". The latter costs $50 and is available from SuperPrint.

From: (Aandi Inston)
Subject: Re: Printing a postscript file from Windows95
Date: Tue, 06 Oct 1998 16:32:06 GMT
Xref: comp.lang.postscript:52488

Amy Johnson  wrote:

>Is this the right newsgroup for this questions?
>This is a first for me.  With our new network (server is Windows NT, my
>computer is Windows95), I can't figure out how to print a PS file.
>"Print" is no longer available in the DOS window and I've tried "copy
> \\Servername\printername" which causes the HP laserjet to blink
>but nothing ever happens.  Any suggestions would be greatly appreciated.

That's the right approach. Try COPY /B instead of just COPY.
Aandi Inston
Visit for info on PostScript, 
PSAlter, psalters, tea, and small furry animals. And stuff.  

2/21/99, MIME type for MS Project files

The MIME type for MS Project files is "application/".
Comments to: Alan Wehmann(
Last modified: Sunday, 2/21/99