cushlomokree said:
Thanks Jonathan
I was afraid that was the answer!
I sure was deluded. I thought VBA was a working subset of VB (without the
ability to create .exe's and .dll's)
Up to & including VB6, that would have been a pretty accurate summary. In
essence, they were both the same language, but with different libraries for
forms.
When I "program" I usually use unmanaged C++ (not .NET), so all this
confusion over VB is my own fault.
Easily done if you're not familiar with the area. I'm sure I would get
completely lost with what appears to me to be C++'s mindbending syntax
I've seen the petition before and I agree with its intent, but somehow I
think MS is not listening.
We had noticed...
Seems absurd that serious developers who have a huge codebase of linked,
binary executables (vs. CLR) would suddenly be deprived of that option for
extending their products.
You won't get any disagreement from me on that score!
As a macro language, I thought WordBasic was fine(Yes . I still keep a
copy of Word95 on my machine because it's faster, and it's NOT using wide
characters). It was actually simple enough for nonprogrammers to
accomplish a lot.
Yes, true for simple tasks. I was quite glad when VBA hit the scene with
Word 97, because I had taken WordBasic about as far as I could go with it,
and there was much more I wanted to achieve in terms of sophisticated
automation. Microsoft did work pretty hard at enabling migration with the
use of the WordBasic object, which could have just about any WordBasic
command appended to it. Furthermore when you upgraded Word 95 templates
containing WordBasic, the code was *automatically* changed to the quivalent
VBA, consisting mostly of lots of WordBasic methods. So Microsoft knew
perfectly well how to do a decent job of migration between a pair of
language far more different than VB6 and VB.NET.
Now you're telling me that VBA is just "OfficeBasic."
Has anyone documented the syntactical differences btw. VB (6), VB (.Net),
and VBA?
In terms of the differences between VB6 and VB.NET, there is a book of
several hunderd pages which describes how to get a project from one to the
other. Microsoft have made the whole thing available online here
http://msdn2.microsoft.com/en-us/vbrun/ms788236.aspx
I bought the book when it first came out. In the appendices in the back,
there is a list of all the keywords, methods & properties that were standard
as part of VB6 and its Forms library. I went through the lot and concluded
that about a third of the VB6 keywords are largely unchanged. A third have
been significantly changed in name, syntax or operation to the extent that
in many cases you aren't going to be able to automate the conversion to the
VB.NET equivalent. The final third have no direct equivalents at all.
You can see a list of the VB6 features changed or dropped here
http://vb.mvps.org/vfred/breaks.asp
As for the difference between VBA and VB.NET, its best to approach that from
the point of view of the differences between VBA and VB6, which are easy to
summarize.
1. VBA uses UserForms rather than VB6's Forms. UserForms are simpler and
with fewer capabilities, but if you are familiar with one, you will have
little difficulty programming the other. Both are significantly different
from VB.NET's Windows Forms.
2. By default, in VBA, the object library for the host application is listed
in the project references, so you can start coding in the application right
away without having to bother setting references.
3. Most of the Office applications have a "macro recorder" which produces
VBA code as a result of you carrying out tasks by hand. The quality of the
code is variable, and not everything is recorded, but it can be exceedingly
useful to help you work out which bit of the object model is involved in a
particular task.
4. In VBA, routines are either Public or Private. VBA doesn't have the
equivalent of VB6's Friend keyword.
Are there "gotcha's" if you choose to bypass VBA and create a
"Word.Application" object in VB (I attempted this, and it seems to work
OK. The main disadvantage in VB when working with the Word object is that
Intellisense does not seem to work.)? You mentioned the integer size
issue...
The main thing you have to realise is that, while you are using the same
object model, you are using it in a completely different language. Most of
the Help files for the Word object model have code examples in VBA. So you
need to know VBA reasonably well if you are going to understand them.
