some questions

[Kris Rudin]

I am trying to export tasks from an existing project to one I'm creating.

Here's what I'm doing:
For Each t In Application.ActiveProject.Tasks
If Not t Is Nothing Then 'prevent reference of null task
Set newTask = newProj.Tasks.Add(t.Name, t.ID) 'using ID of
original task preserves ID numbering in new project (blank lines)
newTask.Start = t.Start
newTask.Name = t.Name
newTask.Duration = t.Duration
newTask.OutlineLevel = t.OutlineLevel
'newTask.Predecessors = t.Predecessors
End If
Next

All is proceeding fairly well, except for a couple of items:

1. For all tasks in the new project, the duration is always displayed with a
question mark ("0 days?", "10 days?"), despite the fact that in the original
plan they are not shown that way, and I'm explicitly copying them, as seen
in my code.
2. For two tasks in the new project (one is a milestone, one is not), the
predecessors value is incorrect. There is an ID there, but it is not the
correct one. All other predecessors are correct.
3. For the erroneous milestone task (in #2), the start date is incorrect,
despite the fact that I explicitly copy it, as seen in my code. All other
start dates are correct.

Can anyone figure out why these things would be happening?

Thanks,
Kris

 

[Kris Rudin]

More clarification - if I omit the line to copy the predecessors, the start
date of the problematic task is set to the correct value.

What the ????

Kris

 

[JackD]

Depending on the start date you are setting this could be correct behavior.
If the start of the milestone is before the finish of the predecessor then
the start of the milestone won't be the start you specified, but will
instead immediately follow the finish of the latest predecessor.

You can turn off the question mark thing with this:
OptionsSchedule NewTasksEstimated:=False

As for the predecessors being wrong, I think I need more information before
I can guess what is happening there.


-Jack

 

[Kris Rudin]

Thanks - the question mark was fixed by correcting the estmated value.

The date being wrong occurs after the wrong predecessor is assigned (verfied
by examining values during execution). I fixed that by setting a "Must Start
On" constraint.

Without the constraint, this happens:
newTask.Start = t.Start
'newTask.start date is correct
....
newTask.predecessors = t.predecessors
'newTask.start is now incorrect

But with the constraint, I've solved that, but the predecessors are still
wrong in 2 cases.

Also, in tracing the value of predecessors, I checked the values of both old
and new tasks pre- and post-assignment. In one incorrect case,
t.predecessors = 38, and then I do this:
newTask.predecessors = t.predecessors
and when I look at the values, t.predecessors is still 38, but
newTask.predecessors is 5.

An interesting note, in both wrong predecessor cases, the wrong predecessor
ID assigned is the current task ID +1.

Also, both wrong predecessors are the first 2 tasks to have predecessors
(ID=4, ID=21). After that, all subsequent predecessor assignments are
correct, even muliple value lists.

Riddle me this, Batman!

Thanks for your help!

Kris

 

[JackD]

Kris,

If you are simply trying to recreate the file, wouldn't it all be easier if
you simply do the following?

Sub copyMyFile()
FileSaveAs Name:="C:\Documents and Settings\foo\My
Documents\PutMyNewFileNameHere.mpp", _
FormatID:="MSProject.MPP"
End Sub

Recreating the file structure through the method you are attempting appears
to have a few problems. The alternative method is SOOOOO simple. I know
which one I would choose.

-Jack

 

[Kris Rudin]

We're not just re-creating the file - the purpose of the new file is to have
basic task information, with no cost/resource/custom field information. This
MPP is for viewing by people outside the company, who aren't supposed to see
internal info - just the status of the project.

So, that's why we're doing it task by task - we only want certain task info,
not all of it. (And for purposes of maintenance, we didn't want to (1) copy
the file (2) remove internal information, because if new internal
information was added, for instance a new custom field, we'd have to go in
and modify the code to remove it. This way, we "build up" the plan with only
the info we need.)

We're still stumped on the weird behavior of the predecessors. We're going
to test this on different project plans, to see if the same mistake occurs,
or if the error is due to something inherent in that particular project
plan.

Thanks for your help,
Kris

 

[JackD]

Even so, I think you are better off just clearing the resources and costs
and custom fields and baselines. That sort of information is easier to deal
with than maintaining precedence.

As an alternative, if they just need to see the status of the project simply
prepare a view which shows the information they should see and use the copy
picture function to send them a snapshot. No need to send them the file if
they aren't going to edit it.
A PDF file is also useful in this regard.
Save as HTML can also give them a limited set of data quite easily if they
want something that is a soft copy as does an export to Excel.

-Jack

 

[John Beamish]

Agreed. Using his approach, Kris is likely to end up with a digital
palimpsest.

 

[Kris Rudin]

I dont' have any choice in the design - this is what our client has
requested. We have gone around and around on how "best" to meet their needs,
and the needs of their clients (who want to see the "scrubbed" project
plans), and this is what they decided they wanted. (Money talks.

So, I'm stuck doing it the "hard" way.

We have definitely determined there is something weird in the original
project plan for these 2 tasks. We are not seeing this weirdness in any
other of their plans. I think we're just going to let this be "acceptable"
behavior, since it appears to be very rare. If we have time/budget at the
end of the project, we may look more closely at this particular plan, and
these tasks, to see if we can find out what's weird. Our first look at
everything seems perfectly normal.

<shrug/>

Thanks for the help/advice!

Kris