Hi CS Hayes,

Let me bring my 20-cents-worth to the table  :-)

Interesting topic.

Because of business dependency on legacy VB(A) applications/projects, MS
can't stop full support of that platform.
And there are a lot of VB(A) projects out there... ;-)
I agree.

But, old man, I think you're right. It is the way to go ...

Here come the 20 cents:

(VB2005, read VB2 005.NET and/or VSTO 2005 SE)

VB2005 vs VB6
I use VB6 only for support to legacy VB6 apps.
I've moved to VB2005 completely for new apps.

VB2005 vs MS Access VBA
MS Access is famous for RAD when it comes to database app development.
With VB2005 (and ADO.net), turn around times regarding delivery of database
app development are (or can be) equivalent.
The VB2005 IDE is ... ahem ... richer, though. (apart from the MS Access
Main/Subform functionality)
What do I favour? Sometimes MS Access, but more and more: VB2005.
Personally, I'd say: 70% VB2005 and 30% Access

VB2005 vs MS Excel VBA
The MS Excel legacy VBA power is humongeous. So no favour when it comes to
delivering Excel development projects.
VB2005 vs Excel: 50/50 with a slight favour to VB2005 because of the
richness of the windows forms in VB2005.
I'm waiting for the Office 2007 fully supported PIA's for Excel. This could
turn things around in favour of VB2005.

VB2005 and MS Word VBA
MS Word development in an enterprise setting: rapid document production
tooling.
There's practically no other (enterprise) interest to MS Word besides:
Getting my data as fast as possible into (presentable) enterprise documents
with the least of efforts.
Because of the hidden binary document specifications of MS Word (in all MS
Word versions prior to 2007), y'd always need
the MS Word application to create documents. So, programming MS Word using
an automation client or using MS Word VBA didn't make
any difference to me.
So before Office 2007, the VB2005 vs MS Word VBA would score: 50/50 as well.
With Office 2007 however and XML being the MS Word document foundation, this
will change.
If you know the internal directory build up of MS Word documents, and the
XML specifications of the dependant XML files to go with it, you can
create MS Word documents using ... notepad.
In case you didn't know: change the .docx or .docm file extensions of MS
Word 2007 documents into .zip and open this renamed file in Windows Explorer
and explore ...
This will change MS Word document production tremendously from a developer's
point of view, once expertise around this subject grows in the development
community.
Like with Excel, I'm waiting for the full Office 2007 interop wrappers to
come available.
Until then, the score for VB2005 vs MS Word 2007 would read: 50/50 but will
change in favour of VB2005.

Hope this was usefull to you

--
Krgrds,
Perry

System:
Vista/Office Ultimate
VS2005/VSTO2005 SE

I have no problem with people disagreeing with me. I don't regard myself as
being infallible, and in fact I learn new stuff about Word all the time, in
many cases from the experiences of others here on the Word groups. Don't
hesitate to disagree with me if you think I'm wrong.

There are various problems with that. I'll describe each one in turn. They
may not be applicable in all cases, but they need to be considered when
making an informed decision.

1. The Office object model is COM-based, and VBA works in-process without
COM-NET interworking. Performance therefore tends to be better when using
VBA.

2. I hope never to hear that hoary old jibe about VBA programmers being
unable to understand object-orientation. When presenting an argument, it is
best not to insult the intelligence of those you disagree with.

3. There are severe problems with deploying VSTO add-ins. The MVPs who have
been attempting it recently have been screaming at Microsoft about it, and
the facilities for doing so are in my opinion thoroughly inadequate still.

4. If your application is primarily controlling Word documents, then the
primary need is for efficient access to the Word object model. Access to the
.NET framework is of much lesser importance, and any advantages of using
VB.NET are correspondingly reduced.

5. The latest VSTO only works with Office 2007. The previous (more limited)
one only worked with Office 2003. if you want an application to support
multiple versions of Office, then you need to use VBA. About 40% of my
customers still use Office 2000 or Office XP, and my VBA library code works
unmodified in all versions of Office from 2000 onwards. Because Microsoft is
still refining the interface between .NET and Office in successive versions
of VSTO, the kind of version independence achieved  by VBA is unlikely to be
matched by VSTO any time soon, which means that coe may have to be rewritten
in part every time you change version of Office, Visual Studio or VSTO.

6. I'm not at all convinced of the long-term commitment Microsoft has to
VB.NET. Public statements by senior people in Microsoft suggest to me that
Microsoft makes no distinction between a language and a platform, and that
when a platform changes, the language inevitably must as well. The idea that
a high-level language is something that insulates your code from the effects
of changes in platform is something which seems to have been forgotten in
Microsoft. Therefore when the successor to .NET comes along (and of course,
it will eventually) unless Microsoft has changed its mind, VB.NET code will
end up being as obsolete as VB6 code has become. Also, it is worth noting
that Microsoft was publicly thoroughly committed to the future of FoxPro,
until the day it announced the product would be discontinued.

The problem is not about having learned VBA. It is that there is a lot of
VBA about, and Microsoft cannot remove support for it without causing all
companies that have VBA code they rely on to delay, perhaps permanantly,
their plans to upgrade to a newer version of Office. As Office makes up
something like a third of Microsoft's total revenue, and corporate sales
form the bulk of that, Microsoft dare not mess with VBA. It will be around
for a while. It is worth noting that three versions of Office have been
released since VB.NET came out, and they all still have VBA. That suggests
that, whatever the Visual Studio people may be saying about Microsoft's
commitment to all things .NET, the Office people are being somewhat more
cautious and pragmatic about it.

If you expect flames from me, I fear you will be disappointed. I'm
interested solely in the truth of the matter, and I have an interest in
making sure I provide the best possible service for my own customers. That
means using whatever technology is best for the purpose, not necessarily
what is the latest thing being pushed by Microsoft.