Stoplight Formula

[Steve Scott]

I have a great milestone formula that is very robust and has been working
well for a while now, I now need to develop it further so that it applies
different rules depending on the Milestone Reporting level has been assigned.
I don't have enough characters left in my custome text field to create the
formula I want so can I do this in a macro or code? If so are there any
examples available?

Thanks in advance

 

[John]

I have a great milestone formula that is very robust and has been working
well for a while now, I now need to develop it further so that it applies
different rules depending on the Milestone Reporting level has been assigned.
I don't have enough characters left in my custome text field to create the
formula I want so can I do this in a macro or code? If so are there any
examples available?

Thanks in advance

Steve,
Yes, very definitely this can be done with VBA. Fellow MVP, Jack
Dahlgren, has several samples of VBA code on his website at:
http://masamiki.com/project/macros.htm

If the sample's on Jack's site still leave you with questions, feel free
to post on the microsoft.public.project.developer newsgroup.

Hope this helps.
John
Project MVP

 

[JackD]

There may be a way to make the formula more compact so you can fit in your
new conditions.
If you post it we can take a look and see what can be done.
Macros are great, but they don't autocalculate.

 

[John]

There may be a way to make the formula more compact so you can fit in your
new conditions.
If you post it we can take a look and see what can be done.
Macros are great, but they don't autocalculate.

Jack,
Although I've never tried it but couldn't an Event driven macro
effectively autocalculate (i.e. perhaps using AfterUpdate)?

John

 

[JackD]

The problem with events is that they are not always reliable. That is they
are not triggered in all circumstances. There is a list somewhere I've seen
which details what doesn't trigger them. So, given the choice between
something that works all of the time (Custom field formulas) and something
that might work most of the time, I choose formulas. What reason is there
not to?

Further, I have a better feeling about a macro which is run explicitly than
one which fires sometimes. I don't have this reservation about "big" events
like project_open , but I do have it on smaller things like ones which fire
in response to a task change.

I'm not saying events are not useful, but just that they are less useful
than some of the alternatives.

 

[John]

The problem with events is that they are not always reliable. That is they
are not triggered in all circumstances. There is a list somewhere I've seen
which details what doesn't trigger them. So, given the choice between
something that works all of the time (Custom field formulas) and something
that might work most of the time, I choose formulas. What reason is there
not to?

Further, I have a better feeling about a macro which is run explicitly than
one which fires sometimes. I don't have this reservation about "big" events
like project_open , but I do have it on smaller things like ones which fire
in response to a task change.

I'm not saying events are not useful, but just that they are less useful
than some of the alternatives.

Jack,
Gee that's too bad. They seem to keep expanding the Project object model
but it doesn't appear they are bothering to fix some of the glitches. I
have even a bigger beef with the Mac side of VBA. I found out that even
though Office 2004 for Mac was "completely" re-designed to better work
with the latest Mac processors and operating systems, the version of VBA
released with Office 2004 is still based on an old version of VB.
Several of the handy features I take for granted when developing VBA for
Project are simply not available when I write VBA code for Excel, for
example, on the Mac side.

I prefer VBA over formulas unless the formulas are very simple. For me
at least formulas can get complex and confusing in a hurry. With VBA I
can do much much more and even the simple stuff is easier to understand
because it doesn't all have to be in one formula. However, I fully
realize that the typical Project user neither knows nor would be
comfortable with VBA.

At times very frustrated,
John