VBA is dead (?)

Topic

New Reply

We hear that VBA will be gone within 2-3 years and NET will take it place. Can anyone give a short scenario of how one will make “macros” in say Excel with NET. Can one start doing this now?

Reply | Quote

Replies

Hi,

At the moment, .Net is not even available for VBA. So anything to do with macros will not change for a while yet. And support for VBA will stay around for quite a while longer.

Reply | Quote

I’ve heard that MS will keep supporting VBA in the next versions of Office; can’t find an authorative quote though.

One great comment I heard was that VB is as dead today as non-NT Windows was in ’93.

Jonathan West has written a great article on some of the options on Fawcette’s VSM: Office and .NET: Better Together?

Klaus

Reply | Quote

Have a quote…
Steven Sinofsky (MS):[indent]

---

“Office will continue to fully support VBA as you see it in Office XP well
into the future. Our commitment will extend at least two full product
cycles at the level we support today and solutions made today will have at
least as much compatibility as we have maintained in Excel and Word from
Office 97 through Office XP.”

---

[/indent]

(not that I care that much… I don’t have a big investment in VBA code, and think a language update offers the chance to get rid of some old legacy stuff, resulting in a cleaner language, including perhaps improvements in the Object Model)

Klaus

Reply | Quote

I’m hoping that the learning curve from VBA to .NET will be shorter or less steep than from WordBasic to VBA. After using WordBasic for 5 years, it was a huge paradigm shift, particularly going from Word’s dialogs-for-dummies editor to UserForms. Either way, we won’t be in a huge hurry to install a new version of Office, so it probably will be late 2003 before I even get a look at it.

Reply | Quote

ASSuME-ing that VBA will be followed by something based on VB .Net, the learning curve from VBA to.let’s call it VBA.Net is not that great for power users and programmer types, but for end users, VBA.Net is harder to use and understand than VBA.

In addition, folkes really better hustle to get rid of the WordBasic object in their VBA code. I’m not so sure that what I’m calling VBA.Net will provide for handing the WordBasic object. Note that VB. Net officially supports upgrading from VB 6 and not from VB 5, so MSFT might pull the same stunt with the . Net stuff and state that VBA 5 cannot upgrade, but VBA 6 can.

And what if MSFT allows all 3 of the .Net languages to be used in Office?

Trying to guess what’s gonna happen is not too productive. I’d suggest:

1. Getting rid of as much of th eWordBasic object as you can.
]
2. Upgrade your VBA 5 (Word 97) stuff to VBA 6 in Word 2000 or Word 2002.

3. Purchase VS.Net to see what it’s got. Note that if you already have various Visual Studio/VB products, you can but VS .Net as an upgrade an dyou can get a $300 rebate (I think the deadline is 30 September 2002).

4. Get one, or more, of the books describing upgrading and look for trouble areas in your current code. For example, get rid of the Variant data type.

Reply | Quote

I haven’t been in the lounge in a long time, but thought I’d put in my in on this subject.

“Note that VB. Net officially supports upgrading from VB 6”

I’m not quite sure what you mean. VS.NET has upgrade wizard that helps port your VB code into VB.NET. Unfortunately, it’s not 100%. I’ve read some comments that it’s probably better to do a total rewrite to take advantage of the functionality of VB.NET instead of putting in a bunch of band-aids trying to port your VB code to VB.NET. Moving to VB.NET from VB5 or VB6 is as big or bigger change than from VB3 to VB4. Another developer I know is using VS.NET and estimates that after getting over the steep learning curve of VB.NET, he’s way more productive using VB.NET than VB6. I’m still trying to get my company to procure a copy of VS.NET.

“And what if MSFT allows all 3 of the .Net languages to be used in Office?”

Actually, I wouldn’t be surprised when Office gets the .NET treatment that all .NET enabled languages(more than 3) will work.

Here’s some links to some articles that discuss “.NET” that may help answer the question, “What is .NET?”

http://www.andymcm.com/dotnetfaq.htm%5B/url%5D

http://www.gotdotnet.com/about_new.aspx%5B/url%5D

http://www.gotdotnet.com/team/clr/about_clr.aspx%5B/url%5D

http://www.oreillynet.com/pub/a/dotnet/200…tdevletter.html%5B/url%5D

As usual with Microsoft, you need to separate marketing from reality. They are tacking the “.NET” moniker on all their products.(SQL Server.NET, Microsoft IntelliMouse.NET, MS Flight Sim 2002.NET, Microsoft Bob.NET, Bill Gates.NET…)

With the .NET Framework(which consists of the Common Language Runtime and the Class Libraries), C++, VB.NET, C#(Pronounced C sharp” – Microsoft’s answer to Java), J#(J sharp i.e. Java), and other .NET enabled languages(Perl, Python, and even COBOL) use the same set of objects/libraries from the Common Language Runtime and Class Libraries. Data types are the same across all languages. Components/classes created in one language can be used in other .NET languages.

Also, a PC installed with the .NET Framework(Win98SE or better) makes installing an app is as easy as copying it to the PC. No more DLL hell or registry baloney.

Of course VS.NET’s claim to fame is rapid application development with more emphasis on web applications and web services(SOAP & XML).

If Office could take advantage of CLR and Class Libraries, then you can do some really powerful stuff.

Reply | Quote

MSFT States that the upgrade wizard officially only supports upgrades from VB 6, tho much VB 5 code will import as well as VB 6 code.

Moving from WordBasic to VBA required major rewrites, in large part, due to some stuff done via the WordBasic object not yielding the same result as woring wit WordBasic in prior versions.

Moving from VBA to “VBA.Net” doesnot appear to have that hurdle, or there ain’t so many such issues.

Economics determines whether to do a total rewrite.
If the imported code works, performance is acceptable, and there will not be much need to modify the code, then no rewrite is needed.

If the app is performance sensitive, or may be subject to modifications, then I believe that it would still be better to start with the imported code, isolate those parts that need changing and incrementally recode.

Moveing from WB to VBA was necessary to use the added features of VBA based versions of Word. If MSFT does FREEZE VBA, then added features in Office would need to be done with “VBA.Net”. However, for existing features, I expect that the import of VBA into “VBA.Net” will be just fine (subject to bugs, etc. in the import, and performance issues).

And, I agree that for the programmer types, VB .Net is better than VB. But we are talikg about Office “macro” languages here. As far as I am concerned, Office has NEVER had a true user-oriented “macro” language. VBA.Net won’t correct this unless MSFT comes up with a true macro front end.

IMHO, if MSFT does allow ALL of the ,Net lanuages to be used within Office, that is likely good, as the ONLY way that will work is if MSFT gets the job done correctly in the first place.

Speaking of performance, I was diddling this AM testing timing with using the collection object instead of Redim Preserve (for those cases in which I do not really know the needed array size).

Ran the identical code in VBA (Word 2002) and VB 6. Got the expected results. Collections are slower than using arrays, but faster than using Redim Preserve.

VB.Net had no trouble importing the code, BUT the tests using Collection object took forever. Actually, not forever, as I killed the critter before it could complete.
Ditto for using Redim Preserve.

I’ll have to research what are the alternative techniques in VB.Net.

Reply | Quote

When you refer to “freezing” VBA, are you referring to MS failing to add features to the language, or to having two different object libraries, with the newer features of the application itself available only to .NET applications? If it’s the former, I don’t think anyone would be particularly alarmed; COM has a lot of mileage left in it. If the latter, it will be difficult to build workarounds for the buggy new features without .NET, and that could be a real motivator…

Reply | Quote

The word, no pun intended, is tjhat MSFT has stated that VBA will not be further enhanced.

Since MSFT has dropped VB development, I doubt very much that they would do VBA development.

So, if you wanna write code for all versions of Word, post word 7, you’ll need a VBA version and a “VBA.Net” version.

Reply | Quote

Well, I’ve decided to go shopping for a Titanium PowerBook G4 running Mac OS X, so it could well be that I won’t be having to learn .NET after all. Now, I’ll see how the Mac does dynamic link libraries and how to drive AppleScript. Or this will blow over, one or the other.

Reply | Quote