Project capabilities

[JackD]

I actually don't think there is a huge amount of fundamental disagreement
here. I even find myself on both sides of the issue. There are different
solutions for different people.

Given the same question "Can I do _______ with Project?" I'd answer
differently for different people. Some people would get a flat no. Not
because they are bad or stupid, but because I think they would not be able
to make it work well if at all. Another major reason for a "no" is need for
stability. It is easy to write simple VBA code. It takes a lot more work to
make it work in every situation. In code I put together for the occasional
need I don't include any error handling. This would be a bad idea if I were
counting on my entire organization depending on it. Most code on my site has
a "money back guarantee". To protect myself I set the price at $0.00.

Other people may get a yes, try this macro type answer. Others might get an
even more detailed response which details what is wrong with the macro I
suggested. It all depends on what I perceive as the skill set of the person
and the situation they are in.

So really the answer to every question is "yes, given enough time, money,
skill and inclination - except for shading the cell background"
Unfortunately each of the given's in that sentence are usually limited in
one way or another.

--
-Jack ... For project information and macro examples visit
http://masamiki.com/project

..

Comments in-line

-Jack

Mike,
Has the dust settled? I thought it had, but it looks like it just got
kicked up again.

I'll reiterate a bit because it addresses some of the issues you raise.
From my point of view, VBA IS a built-in feature of Project right out of
the box. Whether the user has the need, desire, or training necessary to
use VBA is another matter.

Quite an important matter however. Even though in my opinion it is a fairly
simple feature. It should probably be classified as an advanced feature. To
write effective VBA code requires a fairly solid understanding of how
project behaves. It also requires some programming skills. Many people do
not have these skills.

When it comes to finding solutions that
aren't obvious or may seem impossible, I am an optimist. What may seem
like a very strange question [in a post] to us may be very important in
the eyes of the user. If I believe or know that the question can be
answered directly or indirectly, I respond accordingly, even if the
solution is "unconventional". When I suggest a VBA solution I feel I am
simply exposing the possibilities that are often overlooked or
dismissed. My suggestions can be ignored or pursued, it is entirely up
to the user.

No one has any problem with you saying that - at least as far as I have
seen.

-Jack

Jack,
Thanks for checking in. I wondered if any of the MVPs who work with VBA
had an opinion. I was beginning to think I was the guy way out in left
field. (For that matter, I probably still am).

I agree about VBA being an advanced feature. I should have offered that
up earlier in the discussion. And yes, VBA code won't be much good if
the user doesn't good understanding of Project itself.

John

 

[John]

I actually don't think there is a huge amount of fundamental disagreement
here. I even find myself on both sides of the issue. There are different
solutions for different people.

Given the same question "Can I do _______ with Project?" I'd answer
differently for different people. Some people would get a flat no. Not
because they are bad or stupid, but because I think they would not be able
to make it work well if at all. Another major reason for a "no" is need for
stability. It is easy to write simple VBA code. It takes a lot more work to
make it work in every situation. In code I put together for the occasional
need I don't include any error handling. This would be a bad idea if I were
counting on my entire organization depending on it. Most code on my site has
a "money back guarantee". To protect myself I set the price at $0.00.

Other people may get a yes, try this macro type answer. Others might get an
even more detailed response which details what is wrong with the macro I
suggested. It all depends on what I perceive as the skill set of the person
and the situation they are in.

So really the answer to every question is "yes, given enough time, money,
skill and inclination - except for shading the cell background"
Unfortunately each of the given's in that sentence are usually limited in
one way or another.

Jack,
We are on the same page although your perception of a users capability
is probably better than mine. In that regard I might give a "yes" answer
to some poor soul who hasn't a clue of what VBA is. In my view that's
fine because the posts become a history for people to search, and more
than once have I received an e-mail (2 in the last week) wherein someone
asked me about something I posted months ago.

I do take exception to the error handling issue though. The more complex
the code, the more error handling I include. It's not perfect but I want
to make my macros as user friendly as possible. A message that says,
"runtime error", or similar, is aggravating and generally doesn't mean
squat to the user. I personally think better error handling could have
been used in the "Compare Projects" utility because it doesn't take a
lot to make it "krump" and give a meaningless message to the user. And
that code was (I assume) written by professional developers.

John

 

[JackD]

I do take exception to the error handling issue though. The more complex

the code, the more error handling I include.

I'm not disagreeing with you here. I'm saying code should have error
handling.
This makes developing the code more complex.
Error handling is essential if someone other than you is running the code
because they won't know if it succeeded and they won't know how to fix it if
it is broken.

It's not perfect but I want
to make my macros as user friendly as possible. A message that says,
"runtime error", or similar, is aggravating and generally doesn't mean
squat to the user. I personally think better error handling could have
been used in the "Compare Projects" utility because it doesn't take a
lot to make it "krump" and give a meaningless message to the user. And
that code was (I assume) written by professional developers.

John

I completely agree. You will agree that this only makes the bar higher for
those who are trying to craft a VBA solution to a problem though?

-Jack

 

[John]

I do take exception to the error handling issue though. The more complex
the code, the more error handling I include.

I'm not disagreeing with you here. I'm saying code should have error
handling.
This makes developing the code more complex.
Error handling is essential if someone other than you is running the code
because they won't know if it succeeded and they won't know how to fix it if
it is broken.

It's not perfect but I want
to make my macros as user friendly as possible. A message that says,
"runtime error", or similar, is aggravating and generally doesn't mean
squat to the user. I personally think better error handling could have
been used in the "Compare Projects" utility because it doesn't take a
lot to make it "krump" and give a meaningless message to the user. And
that code was (I assume) written by professional developers.

John

I completely agree. You will agree that this only makes the bar higher for
those who are trying to craft a VBA solution to a problem though?

-Jack[/QUOTE]

Jack,
Yeah I agree. We gotta keep that bar up there so people will hold us in
awe )

John

 

[Steve House [MVP]]

I agree completely and go a couple of steps farther. VBA is not a
stripped-down subset of the Visual Basic development environment. Quite the
contrary, it is a super-set of the full-blown VB windows application
development system with added "hooks" in the object and methods models to
allow it to integrate with Office applications. I see it in no way
different from C++, or Java, or Cobol and Fortran fer crying out loud
<grin>, in terms of the analytical and programming skills it requires to
actually do much in it beyond recording a simple macro and playing it back.
To effectively use it to extend Project beyond its out-of-the-box behaviour
requires both a thorough understanding of Project AND a very solid grasp of
both programming principles and practices, object oriented programming in
particular, and the VB language. Some people like John and Jan seem to have
a flair for it, like some people have a flair for learning spoken languages
or the piano, and it seems almost intuitively obvious to them how to
approach a programming problem. I have done some fairly substantial VB
projects in Excel and Access myself. But I believe people with those
abilities are truly a very small percentage of users. The majority of
Office and Project users have neither the background of a programming
"techy" nor the time to achieve sufficient fluency to do much more than copy
code into the VB editor and compile it and in truth there's no reason they
should take the time away from their "day job" to acquire those skills. One
might not need to be a professional developer, but IMHO one needs to be
close enough to it to be a contender.
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs


....snip...

Quite an important matter however. Even though in my opinion it is a
fairly
simple feature. It should probably be classified as an advanced feature.
To
write effective VBA code requires a fairly solid understanding of how
project behaves. It also requires some programming skills. Many people do
not have these skills.

....snip....

 

[Jan De Messemaeker]

Hi guys,

Thanks for the compliments!
IMHO Server is a different application, or if you like, a supplement.
There are quite some competitors of Server around who just as well recommend
and support Project desktop as the planning tool.

Greetings

 

[John]

I agree completely and go a couple of steps farther. VBA is not a
stripped-down subset of the Visual Basic development environment. Quite the
contrary, it is a super-set of the full-blown VB windows application
development system with added "hooks" in the object and methods models to
allow it to integrate with Office applications. I see it in no way
different from C++, or Java, or Cobol and Fortran fer crying out loud
<grin>, in terms of the analytical and programming skills it requires to
actually do much in it beyond recording a simple macro and playing it back.
To effectively use it to extend Project beyond its out-of-the-box behaviour
requires both a thorough understanding of Project AND a very solid grasp of
both programming principles and practices, object oriented programming in
particular, and the VB language. Some people like John and Jan seem to have
a flair for it, like some people have a flair for learning spoken languages
or the piano, and it seems almost intuitively obvious to them how to
approach a programming problem. I have done some fairly substantial VB
projects in Excel and Access myself. But I believe people with those
abilities are truly a very small percentage of users. The majority of
Office and Project users have neither the background of a programming
"techy" nor the time to achieve sufficient fluency to do much more than copy
code into the VB editor and compile it and in truth there's no reason they
should take the time away from their "day job" to acquire those skills. One
might not need to be a professional developer, but IMHO one needs to be
close enough to it to be a contender.

Steve,
Man I thought we had run this into the ground but since I started the
whole thing I feel obligated (actually drawn in) to comment.

I can't speak for Jan but I am certainly not an expert in anything,
especially VBA. I will however admit to having a "flair" for it. I
really enjoy the challenge of figuring out how to solve a problem and
then being able, usually after many hours of frustration, to generate
the necessary code to make it all work. As I stated before, most people
will not share my enthusiasm. However, I still firmly believe in
offering the users multiple options for solving their problems. If they
wish to pursue alternate approaches they can.

By the way, from what I've read and seen in our newsgroups, Project
Server is an "advanced feature" of Project. It is interesting that it's
use if offered more freely as the "way to go" for some posted questions.
Just my observation.

John