How to get LagFormat using Project Object Model

[Eric]

When I access a project file using VB and the object model, I get back a
value for lag but no format, i.e. percent or days. Is this a bug, missing
(but really needed data), or am I just missing something? I know the
lagformat is in the program but I can't find how to access it thru the Object
model.

 

[Eric]

I'm not sure that is correct. When I enter enter days in Project, I get back
something other than minutes, i.e. 1d = 480. Also, if I enter a percent such
as 50%, I get back 5. It seems to be something other than minutes that needs
a unit or lagformat with it.

 

[John]

When I access a project file using VB and the object model, I get back a
value for lag but no format, i.e. percent or days. Is this a bug, missing
(but really needed data), or am I just missing something? I know the
lagformat is in the program but I can't find how to access it thru the Object
model.

Eric,
Like all other time related data stored in the Project database, the
dimension is "minutes". What you see in a view display is the special
formatting Project has applied for you based on one or more option
settings.

Hope this helps.
John
Project MVP

 

[JackD]

According the the VBA help:

"The duration of lag time between linked tasks. To specify lead time between
tasks, use a negative value. String values default to days unless otherwise
specified. Non-string values are interpreted as minutes. Read/write
Variant."

So it appears that the format is not something that you can easily read.
This is not the only example of this in project. There are a number of write
only properties. For example I can set
ActiveProject.Tasks(2).TaskDependencies(1).Lag = "20%" with no problem. But
when I read it it returns a 2. One could make the assumption that lags less
than say 60 are likely to be percentages because in most schedules one is
unlikely to set lag to less than an hour. Another approach would be to
compare the finish vs. start of the successor task and see if you can
confirm the lag that way. Obviously there are some situations where that
would not work (if for example another task was driving the successor).
Personally I'd just treat numbers under a certain amount as being
percentages.

 

[John]

I'm not sure that is correct. When I enter enter days in Project, I get back
something other than minutes, i.e. 1d = 480. Also, if I enter a percent such
as 50%, I get back 5. It seems to be something other than minutes that needs
a unit or lagformat with it.

Eric,
I stand corrected. It seems Jack has done a little more research into
the subject. I'd go with his suggestions. Unless you are working with a
plan that works with sub-hour tasks (e.g. process plans), a lag value
between 1 & 10, (i.e. 10& and 100%), will most likely be a percentage.
Otherwise it will be in minutes.

What Jack said about some Project parameters being unavailable is very
true. Sometimes you just have to think outside the box and find a
workaround approach - that's what keeps it interesting.

Sorry for the miscue.
John
Project MVP

 

[John]

I'm not sure that is correct. When I enter enter days in Project, I get back
something other than minutes, i.e. 1d = 480. Also, if I enter a percent such
as 50%, I get back 5. It seems to be something other than minutes that needs
a unit or lagformat with it.

Eric,
I don't know if you are still checking responses to your post, but a
surefire solution hit me late yesterday. In the "old days", before the
Project Object model was expanded, the TaskPredecessor Property was not
available. However, finding out everything you wanted to know about a
task predecessors in VBA was a simple matter of decoding the Predecessor
string. Using this workaround method, a lead/lag expressed as a
percentage or time could be readily determined. No assumptions, no
magic, just some brute force coding. I used this method on more than one
macro in yesteryear but it sure slipped my mind when your post appeared.

Hopefully this information is not to late to help.
John
Project MVP