Because there's no way to mark wizard-generated code as a special
kind of code that can't have anything dangerous in it. Macros are
limited to a finite set of commands. VBA is not.
But is there also not a very easy way to convert the macros to code?
I read something about that on one of the Access blogs (probably
Clint Covington's).
No, I don't think they do. At least, not until they can replace it
with a managed-code solution. Remember, a huge portion of Access
itself is written in *Access* and delivered as wizards. If VBA were
removed, then those wouldn't work.
Does VSTO allow you to write managed code for use in Word and Excel?
If not, then I don't understand how it's a replacement for VBA in
Word and Excel.
There will always have to be a scripting language in Access. The
question is: how full-featured will it be and will it still be able
to use API calls.
I think they do want to eliminate or at least minimize VBA. I also
agree with their reasoning. I still hold to many of the predictions I
made here:
http://groups.google.com/group/comp.databases.ms-access/msg/5932d13cf554de71
I said, among other things:
My concern is still that MS may be trying to put VBA into legacy
mode.
If that happens, so that developers are forced into the DotNet world,
there will be a tremendous loss of efficiency for developers unless
new
techniques for customization are developed. I suspect that the new
XML
tools may be meant to lessen the hit of leaving VBA behind. MS may
be
ready to put VBA on a pedestal and place a spotlight on it as the
development tool of the future. Who knows? I don't see it that way
yet. I'm seeing VBA as being a potential sacrifice to DotNet web
integration. I am going to take Larry's advice seriously and try to
be
prepared for any eventuality. Maybe the PDC 05 didn't talk about VBA
much because it wasn't in yet. I'm still leaning toward the
deliberate
de-emphasis theory. Maybe Access will be dumbed down via a VBA
lobotomy in the future. It doesn't make sense for MS to push VBA
anymore. Besides, some XSLT, C#, and SOAP are good for the soul
until
we find out how MS really intends to do RAD.
Comments from PDC05 on WCF:
And we observed that, in most cases, enterprises that are very
successful in taking heterogeneous environments and having them work
in a cohesive way do messaging. And they do something very
important. They do Protocol Integration. That's the way they put
things together. They don't stick everything in one system or inside
of one database. They just have messages flow between one system to
another system. And we committed ourselves at that time, seeing that
observation, to doing WCF. And we also committed ourselves at that
time to doing full blown interop. That's when we sort of flipped the
switch and said, "You know what? We're going to talk to everybody."
....
SOAP enables rich extensibility and security.
....
Application Protocols: POX [Plain Old XML], RSS, ...
Infrastructure Protocols: SOAP, WS-*, ...
....
XML is one of our core architectural commitments.
....
But the key thing is Protocol Integration, XML and then avail yourself
of either Metadata or SOAP as appropriate. But that's where we're
betting as a company, on the fact that protocols are important and
we've got a lot of investment in WS-* and we're going to continue to
do that and we believe that's the center of gravity for us moving
forward.
....
XML, XML, XML, XML.
-- Douglas Purdy, COM 326, PDC05
James A. Fortune
(e-mail address removed)
