Tips for Use of MS Project (e.g. on \\numiwinctr1)
Introduction
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 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.
Customizing
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.
- Use the mouse to highlight the MS Project icon in the Program
Manager Window.
- 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
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
MattP@RevereGroup.Com
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".
Bulletins
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
Folks,
Here is the procedure for opening MS Project files from NUMIWINCTR1
Current folder. This procedure should insulate you from problems with
external tasks.
- 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.
- Open up MINOS_2_0
- 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.
- 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.
- Open up the MINOS_2_0 window and save. You should select "Yes to all"
to save all files with the updated path.
- 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: quite@dial.pipex.com (Aandi Inston)
Subject: Re: Printing a postscript file from Windows95
Date: Tue, 06 Oct 1998 16:32:06 GMT
Xref: fnnews.fnal.gov 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
>temp.ps \\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 quite@dial.pipex.com
Visit http://www.quite.com/ 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/vnd.ms-project".
Comments to: Alan Wehmann(wehmann@fnal.gov)
Last modified: Sunday, 2/21/99