does VBA have legs?

[philr]

I know MS is trying to move VB programmers to VB.net. I don't do much
programming and am considering learning VBA for expanding my current needs
but don't want to spend a lot of money purchasing manuals or spending time
learning VBA if it's going to die in a couple years.

Will MS be supporting VBA into the future? What is a good VBA book or even
VB book for someone with some programming experience (non-OOP) to start? VBA
for Dummies doesn't seem like it covers very much. Other advice?

TIA, Phil

 

[Howard Kaikow]

See the list of WordVBA books at
http://www.standards.com/links.html?WordVBABooks.

As far as I know VBA will be in the next version of Office.
I suspect that VBA will be supported in Office at least as long as WordBasic
has been supported.
As to when MSFT stops enhancing VBA, ...????
It does pay to learn VBA as that will familiarize you with the object model.
Start with Steve Roman's Writing Word Macros for Word VBA.

Gary Cornell's Visual Basic 6 From the Ground Up for VB 6.

You could also start with VB .NET by reading:

1. The VB.NET Step By Step book from MSFT Press.
2. Paul Vick's The Visual Basic .NET Programming Language
3, Francesco Balena's Programming Microsoft Visual Basic .NET.

 

[Jonathan West]

I know MS is trying to move VB programmers to VB.net. I don't do much
programming and am considering learning VBA for expanding my current needs
but don't want to spend a lot of money purchasing manuals or spending time
learning VBA if it's going to die in a couple years.

Will MS be supporting VBA into the future? What is a good VBA book or
even
VB book for someone with some programming experience (non-OOP) to start?
VBA
for Dummies doesn't seem like it covers very much. Other advice?

TIA, Phil

Hi Phil,

I'm pretty sure that the next version of Office will still have VBA,
possibly in parallel with an embedded version of VB.NET that has the same
sort of relationship to the standalone version of VB.NET that VBA has to
VB6.

Beyond that, there are no public statements from Microsoft. They don't
generally announce features that far ahead. So your guess is as good as
mine.

Certainly, plenty of people have been pointing out to them how damaging it
would be if they were to drop VBA. I have done so myself, see the following
article.

Office and .NET: Better Together?
http://www.ftponline.com/vsm/2002_08/magazine/departments/guestop/

As for books, there are a series of book reviews at http://word.mvps.org/
and a large number of articles and code samples at the same site. You might
find these introductory articles particularly useful for Word VBA
programming

Getting To Grips With VBA Basics In 15 Minutes
http://word.mvps.org/FAQs/MacrosVBA/VBABasicsIn15Mins.htm

How to create a Userform
http://word.mvps.org/FAQs/Userforms/CreateAUserForm.htm

 

[Howard Kaikow]

I really hope that MSFT does not come up with an embedded VB.NET that is in
any way different than the real VB .NET,
Not only would that increase MSFT's development costs, it would just
perpetuate problems analogous to the differences between VBA and VB,
especially, if MSFT foolishly has a different forms engine in Office than in
..NET.

oh well, I'm sure that MSFT has considered this already, and the decision
has already been made, so all we can do is keep out fingers, toes, eyes,
legs, arms, etc. crossed, and hope!

 

[Jonathan West]

I really hope that MSFT does not come up with an embedded VB.NET that is in
any way different than the real VB .NET,
Not only would that increase MSFT's development costs, it would just
perpetuate problems analogous to the differences between VBA and VB,
especially, if MSFT foolishly has a different forms engine in Office than
in
.NET.

oh well, I'm sure that MSFT has considered this already, and the decision
has already been made, so all we can do is keep out fingers, toes, eyes,
legs, arms, etc. crossed, and hope!

We aren't going to know until they produce it.

My concern is that there are a large number of cases with the VBA forms
engine where it makes sense to iterate through the Controls collection,
which is a collection of late-bound objects. The techniques for dealing with
these depend on knowing for instance that a Caption and a Checkbox have a
Label property while a TextBox has a Text property. The Windows Forms engine
changes the names of some of these properties, and so late-bound code is
going to have to be rewritten if and when VBA stops being supported. I'm not
looking forward to that day, as it means I will have to support at least two
parallel code bases on different versions of Office.

I'm hoping that they extend thwe WinForms library so that it offers synonyms
for the relevant properties where the name has changed, so that as much
late-bound code as possible can be converted automatically without needing a
manual rewrite. I'm not all that hopeful, because only about a third of the
propperties and objects of VB6 Forms managed to get translated without
modification of the name or behavior, to the severe detriment of any ability
to run an automated conversion.

 

[Howard Kaikow]

Yes, there will be lots of coding changes required.

 

[philr]

Thank you both very much,

If I get a book, like your recommended VB6 From the Ground Up or the
O'Reilly book, it's often confusing what relates to VBA since it is a subset
of VB. Is it just a different set of commands that are different between
them or where one places the code?

TIA

 

[Jonathan West]

Thank you both very much,

If I get a book, like your recommended VB6 From the Ground Up or the
O'Reilly book, it's often confusing what relates to VBA since it is a
subset
of VB. Is it just a different set of commands that are different between
them or where one places the code?

The following are the key differences between VB and VBA

1. The VB Forms library is not supported in VBA. VBA has UserForms which
have a smaller set of capabilities.

2. VBA cannot be used to create standalone executables. VBA code is embedded
in some fashion within the files of the parent application. How exactly this
is done varies from application to application.

3. For each application that has VBA, the object model for that application
is automatically available to you. With VB you have to set a reference or
create an object in order to access the object model of the application.

Quite a lot of the content of most books on VB deals with Forms. VB books
rarely deal in more than the most superficial way with the Office object
models. If you decide that the remaining information in the book is worth
the money, then go ahead and buy it.