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 "http://support.microsoft.com/support/", 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 FileMichael 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
- Use the mouse to highlight the MS Project icon in the Program
- Under the "file" menu, choose Properties.
- Make sure that the working directory entry is one for which you
have write privilege--e.g. your own directory area.
- If a change was made, mouse click "ok".
- Go to the file manager and copy
"\\numiwinctr1\numiuser\Global.mpt" to the working directory just
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
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
"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
extensionThe 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 FieldsIn 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 SizeDave 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
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