Microsoft Says VBA Is Here To Stay

Angostura writes "Microsoft's team blog for Microsoft Excel and Excel Services has responded with a denial to the earlier report that Visual Basic for Applications will disappear from Windows Office in 2009. The Slashdot discussion on the report on Tuesday got pretty animated."

Comments

So Microsoft is at least still a *little* evil

[sapone]

If they had they rid the world of VBA on top of publishing their binary specs in an Open Source compatible way, their reputation bar might have ended up on the "good guy" side :).

Re:So Microsoft is at least still a *little* evil

[Anonymous Coward]

And if it's true that VBA is sticking around, then the folks running the Mac BU are liars. Either way, Microsoft can't be trusted.

Re:So Microsoft is at least still a *little* evil

[kestasjk]

There's no way they were going to release an Office suite without any macro capability, but the blow is that they aren't replacing it with .NET .

Re:So Microsoft is at least still a *little* evil

[wilder_card]

"Publishing their binary specs in an Open Source compatible way"? Surely you're not referring to OOXML?

Re:So Microsoft is at least still a *little* evil

[innerweb]

That is actually quite funny!

InnerWeb

Re:So Microsoft is at least still a *little* evil

[smittyoneeach]

Not necessarily. If the main VBA users are the PC-based ones, then MS could drop Mac support, retain PC, and the story is "reasonably" clear.
In any case, with the number of people involved in frobnicating the decision, there really isn't a need to label anyone a liar. Policies are variables, not constants, and get new values assigned to them frequently during business execution.

Re:So Microsoft is at least still a *little* evil

[Your.Master]

He's not. He's referring to this:

http://it.slashdot.org/article.pl?sid=08/01/17/1553206

Re:So Microsoft is at least still a *little* evil

[Anonymous Coward]

I work with big banks on the fixed income side, and most traders have some excel spreadsheets with custom macros developed by internal IT. MS has to keep new version backward compatible. There is no way MS will break these spreadsheets, or else they'll piss off plenty of rich people and big companies.

Re:So Microsoft is at least still a *little* evil

[kestasjk]

I was hoping they'd have some sort of transitional .NET language. Remember that Office 2007 breaks plenty of 2003 macros, so forcing developers to update macros for new versions isn't out of the question by any stretch.

Re:So Microsoft is at least still a *little* evil

[Schmodus]

Citation needed here.

Re:So Microsoft is at least still a *little* evil

[cp.tar]

Or the Slashdotter who predicted VBA will be "put back", making MS "the good guy", while at the same time screwing over their customers once again.

Re:So Microsoft is at least still a *little* evil

[Anonymous Coward]

This is NOT wikipedia. YOu cannot demand references here.

Re:So Microsoft is at least still a *little* evil

[Anonymous Coward]

but the blow is that they aren't replacing it with .NET This is getting tiresome. So +5 insightful/informative on the last article went to anyone claiming Microsoft was the devil for replacing VBA with .Net (VSTO, or Visual Studio Tools for Office). Now it's going to anyone who can still find the devil angle by calling this a failure for .Net.

Newsflash: VSTO does everything VBA does and more, has been available since Office 2003 came out, was massively updated for the new framework and Visual Studio version, and will continue to be available for every future version of Office for Windows. The only "blow" for VSTO developers like me is that Microsoft still doesn't have a roadmap to put VSTO on Mac. Probably won't be long, considering that Mono and Silverlight show you can get the .Net Framework and Winforms/WPF working fine on a Mac. Now if MS could make a real portable Winforms/WPF, they could start running their giant glob of Office code through the managed C++ compiler and we could run the same Office code on Mac and Windows. I know this is the very picture of open source dystopia for some people, but as someone making a good living writing .Net apps that extend Office, I don't see a downside for devs or users ;)

Re:So Microsoft is at least still a *little* evil

[Planesdragon]

Newsflash: VSTO does everything VBA does and more Really?

you mean I can hand someone a disk with "office" on it, tell them to install a few additional components, and they can go right into "easy" programming with VSTO?

Wow. And here I thought you needed a several-hundred dollar Visual Studio license to use VSTO. On top of the several-hundred dollar office license.

Re:So Microsoft is at least still a *little* evil

[Imsdal]

I should probably have chosen a nick of ExcelFanBoyOne, as it seems like every other post I make here is about how great Excel is, but GP is actually right. Excel 2007 macros have a huge bunch of compatibility issues.

The ones I have run into in particular are regarding charts. Stuff like changing background colours or patterns etc. Also, the macro recorder in 2K7 doesn't record a lot of things that were recorded earlier. Again, charts are a major problem. Start recording a macro, then drop the background color for a chart and stop the recording. The macro will be empty, which wasn't the case in 2K3 and earlier. Extremely annoying as it really forces you to dig deep into the object model. Ugh!

Re:So Microsoft is at least still a *little* evil

[Anonymous Coward]

Newsflash: VSTO does everything VBA does and more Really?

you mean I can hand someone a disk with "office" on it, tell them to install a few additional components, and they can go right into "easy" programming with VSTO?

Wow. And here I thought you needed a several-hundred dollar Visual Studio license to use VSTO. On top of the several-hundred dollar office license. You're changing the argument and therefor quoting me out of context. Custom newsflash for "Planesdragon": VBA is STILL THERE for people who want to use it as you described. What are you harping about? My post was about how VSTO *is* the .Net "replacement" GP was complaining doesn't exist. Do you even care, anyway--do you do or support office development?

Re:So Microsoft is at least still a *little* evil

[Anonymous Coward]

>> Newsflash: VSTO does everything VBA does and more
> Really?
> you mean I can hand someone a disk with "office" on it, tell them to install a few additional components, and they can go right into "easy" programming with VSTO?
> Wow. And here I thought you needed a several-hundred dollar Visual Studio license to use VSTO. On top of the several-hundred dollar office license.

Since Office accessibility (the Object Model) is just COM, and .NET naturally supports COM, and additionally, Office 2007 has a PIA (Primary Interop Assembly), you can write plugins in C++/COM, Managed C++/.NET, C#, Visual Basic, VB.NET, or any other language that supports COM.

You can even download the free Express Editions of Visual Studio (2005 or 2008 editions) and write your own code. Or you can download the GNU toolchain or just download Microsoft's compilers and use notepad. Microsoft would prefer you to buy VSTO, and VSTO makes it very easy, but if you are competant, you should be able to make add-ins with the tools you can download and the MSDN library. There are newsgroups with very friendly people including MVP customers who like to answer questions if you get stuck, and there are even helpful Microsoft employees surfing these newsgroups and replying non-anonymously.

The point is that you have choices. VBA comes with Office, and is integrated into the applications, but it's not the most powerful language/platform for writing plugins. VSTO is better (and why Microsoft makes you pay for it). C# Express Edition (2005 - haven't played with 2008 yet) is my personal favorite choice - using XNA Game Studio Express and C# Express to make my wireless XBox 360 controller control PowerPoint slide show was a recent fun project I wrote (it could also be done with C++ and XInput or C# and XInput with PInvoke). I was also considering buying a bluetooth puck and making it work with my WiiMote as well. Someone at Microsoft made a C# library to interoperate with the WiiMote and released it on CodePlex. Microsoft makes Windows and Office and Development Tools so that people can use them as the foundation or platform to build bigger and better things. It just so happens that there's a lot of money in it as well. Microsoft is a business after all - you need to have an income in order to dedicate resources to making products.

Disclaimer: I work at Microsoft. It's nice to work at a place which enables you to work with some of the best minds and build products that touch the lives of hundreds of millions of people, even if the feature you work on only matters to 1% of those people. 1% of 500 Million people (who run Office) is 5 Million people.

Re:So Microsoft is at least still a *little* evil

[rtb61]

Now that is an utter and total lie. M$ will with out any qualms or favour break every macro in every spreadsheet in they believe it will make them money and they have already done it once. I likeed the simple little macro language that cam with every spreadsheet program, sure there were some differences but it basically followed the same logic as the spreadsheet program itself.

Then the asshats at M$ wanted to make more money selling software licences for Bills baby, VBA, so fuck all the customers using spreadsheet macros, we will force them to change to VBA by dropping support for spreadsheet macros, and buy an additional software licence if they wanted the full program and the manual, at the same time we will use our monopoly to try to force every other company to incorporate a M$ VBA macro licence in their programs as well.

So will M$ fuck over the customer, in a heart beat.

Re:So Microsoft is at least still a *little* evil

[DutchMasterKiller]

I have had issues with macro's (2003 vs 2007). I just copied and paste macro code from 2003 editor to the 2007 editor and it still worked. Recording the macro the same as I did in 2003 didn't work. Mine was a simple one. I have a shortcut key to quickly print 1 letter on letterhead paper and 2 on blank.

that was a close one.

[kellyb9]

Oh thank god... don't know what I'd do without that!

Re:that was a close one.

[angus_rg]

You'd have more free time thanks to automating it in Perl.

Re:that was a close one.

[joschm0]

Insightful? Be careful with the sarcasm, someone may take you serious.

thinkofthechildren

[Anonymous Coward]

Probably a more applicable tag now than ever.

ISOfication of OOXML vs VBA

[jkrise]

If OOXML is to become an ISO standard fully implemented in Office 2009; VBA and binary blobs will have to be deprecated and removed from the feature list.

Else, after ISO approval is sought and obtained, MS might claim it is deprecated but still provide support in Office..... either way, confused times ahead for the Office cash cow, methinks.

Re:ISOfication of OOXML vs VBA

[morgan_greywolf]

Agreed. VBA obviously can't be part of the ISO-ificated OOXML. VBA is probably going to be considered a 'legacy' feature, with recommendations that customers do new development on VSTA/VSTO.

If history is any judge, many VBA apps will one day not work in future versions of Office anyhow. MSFT does plenty to break compatibility between releases. In fact, some VBA apps developed for Office 97 won't work on Office 2000 or later.

Re:ISOfication of OOXML vs VBA

[maclizard]

Good freakin' point. An ISO standard cannot implement OS specific code.

Re:ISOfication of OOXML vs VBA

[ozmanjusri]

If history is any judge, many VBA apps will one day not work in future versions of Office anyhow.

Actually, that should happen sooner rather than later, so this announcement is a retrograde step.

DDE, OLE, COM and DCOM are fundamentally flawed models which were developed in a much less fraught security environment than we have now. VBA is heavily tied into that same flawed architecture.

Microsoft has tried to address the exposures by disabling macros by default in Office, but the control they provide isn't fine-grained enough to do more than pass the buck to the customers who have to enable the lower security levels to get their documents working.

They do have an answer in .NET, but until Office is re-written for that platform, and until there's some sort of converter for the massive collection of existing VBA to VBA.NET, they're stuck with the risky and clunky security fix.

Re:ISOfication of OOXML vs VBA

[MightyYar]

I've got no problem with them revamping VBA and breaking things here and there to make everything more robust. I'd much rather fix existing macros than start from scratch.

We're smarter now and we typically make web apps, but when Excel 5.0 (IIRC) came out with VBA, it was like geek crack. We made so many VBA macros that it seems like that was all I did for a few years. Now, practically our whole measurement lab relies on VBA in some way or another. It would be quite a bit of work to re-write all of those little macros.

Re:ISOfication of OOXML vs VBA

[jimktrains]

VBA is very nice and helps implement little features that come in handy, especially in Excel.

I don't think there is any reason VBA cannot be part of the standard, as long as it itself is standardized. There is no reason that this tool should be removed because of dumb users. The default setting in office is to not allow macros and if you want to use them you have to turn them on, I'm perfectly fine with that.

Re:ISOfication of OOXML vs VBA

[samkass]

DDE, OLE, COM and DCOM are fundamentally flawed models which were developed in a much less fraught security environment than we have now.

And in a much more resource-constrained environment. There were definitely models that worked much better, such as CORBA, SOM, etc., but doing things right consumes a lot more resources, so tends to be less performant. It's only when we got gobs of extra computing power, bandwidth, etc., that we're able to make interfaces that are both secure and performant. I suspect if we're ever constrained again, most folks will choose performance over security again, so I'm not really sure it's the security environment enabling the decisions, even now.

Re:ISOfication of OOXML vs VBA

[Dan667]

All of my perl scripts still work. I build a bunch of vba crap and then they broke with new office versions so I built the same functionality with perl (Excel::spreadsheets) and you know what, they still work. Yea for perl!

Re:ISOfication of OOXML vs VBA

[MrNemesis]

Can someone more familiar with theses document formats please clarify:

Surely the only sensible place to implement a macro runtime is in the application itself, and just use a meta-object to store the code in the doc itself...? Wouldn't it make more sense for the doc to just have a standardidsed API that any macro-enabled application that supported the format could interact with?

Apologies if this is already what it does, but saying "removing support for VBA from OOXML" seems to suggest that OOXML needs to have specific support for every macro language that can be bound to it.

Re:ISOfication of OOXML vs VBA

[Anonymous Coward]

I can definitely state that this is a fact for Canadian National railroads. I spent many summers there converting their spreadsheets from Lotus to Excel.... and then later from Excel to newer versions of Excel, maintaining compatibility with updates, etc etc etc. Even switching underlying Windows versions had some effects... (i.e. Win 3.x > WinNT/9x)

Re:ISOfication of OOXML vs VBA

[Anonymous Coward]

Um, sorry but SOM sucked (overengineered, with no clear vision or purpose).
CORBA could've been good but never amounted to anything.
COM, on the other hand, was/is one of the most successful component archictures in history, with dozens of companies making thousands of components.

Re:ISOfication of OOXML vs VBA

[shutdown -p now]

DDE, OLE, COM and DCOM are fundamentally flawed models which were developed in a much less fraught security environment than we have now.

How is this insightful? DDE has been deprecated for ages, and has no connection whatsoever with COM, and only in part a common goal with OLE. COM and OLE are also very different things, though the latter certainly uses the former (similar to how, say, JSP relies on Java). There is nothing "fundamentally flawed" about COM, most certainly not anything that has to do with security - it's just a standard API and ABI for components on Windows, very simple at its core. DCOM is just an object remoting framework on top of COM, same as Java RMI is a remoting on top of Java; it's still widely used in enterprise applications running on Windows servers with no security issues, so I'd hardly call it "flawed".

They do have an answer in .NET, but until Office is re-written for that platform, and until there's some sort of converter for the massive collection of existing VBA to VBA.NET, they're stuck with the risky and clunky security fix.

They don't need to rewrite Office in .NET, just like they didn't need to rewrite Vista in .NET. They just need to make it possible to extend Office with .NET components. And guess what, it's been there for a long time already, and the recently released VS2008 comes with all the Office development tools fully integrated. (And, on the other hand, .NET and WPF are considered the "officially recommended" way to develop applications for Vista, so it's .NET all the way now in Windows world...)

Re:ISOfication of OOXML vs VBA

[sco08y]

Microsoft has tried to address the exposures by disabling macros by default in Office, but the control they provide isn't fine-grained enough to do more than pass the buck to the customers who have to enable the lower security levels to get their documents working.

I have a few macro-enabled Office documents that I signed with a CAC. It's actually pretty easy to do, and any time I save an update to the macros it automatically prompts me for my CAC. It works pretty nicely.

In a totally unrelated announcement...

[Anonymous Coward]

...Msoft also reported that they have never in the past, nor will ever in the future, backpedal on any announcements they have made, in order to save face, or calm the nerves of any of their customers they might upset.

--
Anybody interested in buying some prime waterfront real estate in Florida at a bargain price?

Of course,MS is catering to their real customers

[Coopjust]

And despite the security problems that have plagued users for years due to VBA viruses, Microsoft won't remove VBA from Office.

Interestingly enough:...

While it's true that VBA isn't supported in the latest version of Office for the Mac and the VBA licensing program did close to new customers last year, we have no plans to remove VBA from future versions of Office for Windows

Looks like MS may be crippling the Mac version to stop enterprises from moving on from Windows.

Cue the Yack-son 5

[smittyoneeach]

V - B - A
Easy as one, two, thray,
Do arrays the mangled way,
Rather Python any day,
Market penetration means you stay,
OK, this post is turni--

Why bother?

[CSMatt]

If this is some ploy to get Mac users who need VBA to switch back to Windows I don't see how it would help at this point. Mac users can just use Windows Office in CrossOver Mac.

Re:Why bother?

[EXMSFT]

Or more likely, VMware Fusion or Parallels...

Re:Why bother?

[Bill, Shooter of Bul]

It raises the cost and complexity of using the mac platform. Crossover isn't free, nor is parallels.

Re:Why bother?

[sconeu]

That's fine with MS. You have to buy a Windows license to do that.

That's not the problem

[Apocalypse111]

Customers don't want VBA to go away.

They want the damn ribbon to go away!

Re:That's not the problem

[ChefInnocent]

I don't know why you were modded 'Troll'. I think your statements are accurate. There are way too many lines of VB code written for businesses to want it to go away. If they had to re-write those lines (no matter what new language will be, or what the quality of the VB is), they would more likely abandon the need to upgrade. As for the ribbon, I haven't seen it, but that might be because my company didn't think it was necessary to upgrade to the current version of Office.

Whether we like it or not VB is here to stay. The cost to convert the older stuff is way too high.

Re:That's not the problem

[Tacvek]

Customers don't want VBA to go away.

They want the damn ribbon to go away!

Indeed, or at least make the ribbon easy to customize, like the toolbars (and menus) used to be. My understanding is that the system can be customized using .net assemblies, but doing that is difficult even for the few users that know how to do it. It is all but impossible for the average user.

Re:That's not the problem

[doktor-hladnjak]

I believe there are even third party tools out there that will write the necessary RibbonX for you to get the customizations.

VBA for Mac

[christurkel]

VBA for Office Mac was dropped because AppleScript is far more powerful for the task and by dropping VBA you hinder cross platform compatibility. Devious.

Re:VBA for Mac

[marcello_dl]

Devious but now VBA is not cross platform anymore, which makes it even less appealing for people who cater to a mixed audience. Not that I see many cases where passing around documents with embedded scripts is the way to go, but YMMV.

Unless, maybe, openoffice support of VB/VBA is decent.

Re:VBA for Mac

[listen_to_blogs]

Good point Chris! Its definitely bad for cross platform compatibility. Can you elaborate more on how AppleScript is more powerful that VBA? listen_to_slashdot

Re:VBA for Mac

[CitizenJohnJohn]

"by dropping VBA you hinder cross platform compatibility."

Cross-platform compatibility has never been terribly good anyway. I'm a non-programmer Joe Schmoe user who knocks up Excel macros because it's a convenient platform - everyone in my office has it. When I started I had a hell of a job figuring out why my macros worked in - if memory serves - Office 2000 for Win but not Mac Office 2001. Turned out there were functions that were simply missing from the Mac version, even though it was released later.

That I hit this problem for the very simple stuff I was doing suggests to me that cross-platform development of Excel macros has always been a pain in the bum. Does anyone out there actually bother? Wouldn't you just pick an Excel version and stick with it to reduce development headaches?

Would have been a mixed blessing

[HangingChad]

I absolutely hate VBA but it's conflicted because I've made so much money untangling some spaghetti coded VBA nightmare cobbled together as a spare time project that became a legacy application no one can live without.

Hate the language, love the money from fixing it.

Re:Would have been a mixed blessing

[Echolima]

I agree with you here, money to be made with fixing VBA.

I know myself hate the fact that because there is VBA in Excel people assume that they can use Excel as a database of sorts, and create software strictly in Excel.

We have some pretty messy Excel apps here, some not worth untangling.
Maybe if there was no VBA in excel, people would start to learn Access (at least) or another 'programming' tool.

Re:Would have been a mixed blessing

[Anonymous Coward]

This shows one of the many reasons why Windows is being considered rather a business platform than an operating system: you use it because of the money flow it creates, not for solving problems.

Re:Would have been a mixed blessing

[S.O.B.]

Now you can make money converting VBA macros to AppleScript for all those Mac users out there.

And the money train keeps chugging along...

Re:Would have been a mixed blessing

[chris_mahan]

Nooo, not access...

I have an Access 97 database that was built ages ago that I have to support (inherited from the business) and now I'm hitting datababase size limits and it's a zoo. There are module function calls in the queries... The horror!!!

Re:Would have been a mixed blessing

[PitaBred]

You should just about be able to export the tables to SQL server, and then just use linked tables rather than the internal ones... module calls can't directly be in the queries as far as I know, their returns or values can just compose part of the query string. But I may be completely off-base.

Re:Would have been a mixed blessing

[chris_mahan]

Thanks, that's a thought.

I'll play with that a bit ans let you know.

Re:Would have been a mixed blessing

[Jozef Nagy]

There can be problems with upsizing tables. I'm sure you didn't mean to insinuate that it's always straightforward, so I'd like to be clear to the less experienced people. Upsizing a table can be trivial in some environments. However, in a large production environment using legacy Access MDBs, this can wreak havoc. For example, the table in Access may not have a key on it. In order to be able to run UPDATE queries in Access to a linked table from SQL Server 2000, the table has to have a key. As you can guess, adding a key to a table that previously had none could break any INSERT INTO queries that aren't grouping by the fields used in the key. So now you have to go search for queries that insert records into that table. In a large environment, good luck with that.

Another problem with upsizing tables in a complex environment full of interlinking Access databases: A given table in Access might be linked to from other Access databases. If you upsize the table and create a link to the SQL Server table, the other Access databases' links will break. They will not follow the link to SQL Server. So now you have to find all the Access databases in production that link to that upsized table and directly link to SQL Server in each of those Access databases.

I could go on...

As for your other statement: you CAN in fact call module defined functions from within a query in Access. This is a great feature to have in limited situations. It's no different from how SQL Server lets you use user defined Functions from within Stored Procedures. So now you have yet another migration related headache.

Re:Would have been a mixed blessing

[DKelley]

Don't worry, HangingChad, there are *plenty* of .NET "programmers" out there banging out spaghetti code in .NET. You'll have the joy of being paid to fix crap code for a LOOOONG time....

Re:Would have been a mixed blessing

[Billly Gates]

I once had an old boss who loved WindowsNT over Netware back in 99. Because it was a piece of crap it would mean a bigger budget for his department and more jobs for IT professionals and larger salaries.

Not being able to find IT work again when the .com crash happened I empathize with him in disbelief because it makes alot of sense.

I should have learned more .NET and ASP rather than Java. Thats where more nursin gis needed but it goes agaisnt the ethics of why IT exists in teh first place and the goal of work. ITs to make the company money.

Re:Would have been a mixed blessing

[Master of Transhuman]

Access?

Oh, hell, no. That thing is a joke. Corrupts its files if you breathe on it.

People need to realize that apps developed with proprietary software of any kind are BAD NEWS. I don't how perfectly it does a particular job that a particular company needs done. It's bad news in the long run. Either the company that makes it will break it, or the company itself will be bought, or go out of business. Look at SQR, the database report writing language. That thing has been sold a half dozen times, and currently resides with PeopleSoft IIRC. Sure, its still "supported" - except nothing has been to really enhance it in years. It's crap. Nothing it does can't be done in Perl and probably better and more clearly.

Apps should never be developed in proprietary macro languages, or proprietary script languages, or proprietary development languages, period. I don't care how many millions of lines of code have been written in Ryan-McFarland COBOL or frickin' IBM RPG II (or III) or VBA or whatever anybody cares to cite. It will have to be rewritten in an open language sooner or later.

The issue is not whether it has to be done, it's how it should be done. Companies with apps in legacy and proprietary languages need to simply PLAN AHEAD. Budget for re-engineering over time. If your company is not going anywhere, who cares how long it takes to convert? By doing it this way, it won't cost an arm and a leg over time and it will afford some future disaster that will cost an arm and a leg.

Actually, no. Did you RTFA before submitting?

[BobMcD]

The link that _I_ clicked took me to a blog that said that VBA was no longer supported, and that the licensing program had gone away. To me this means 'dead'. No support and no license means that no reputable vendor is going to nail any new shingles to this product. Any future offerings using VBA are destined to be either snakeoil or shareware.

Am I missing something here?

Well, that doesn't matter

[El Lobo]

We bashed them when we read that they wante to drop it. let's bash them because they don't. Hell, this is Slashdor, isn't it?

Re:Well, that doesn't matter

[ozmanjusri]

Why is this insightful?

There are no comments bashing Microsoft at all so far, let alone claiming they should retain VBA.

Pandering to shills may get you mod points here, but let's keep it real, hey?

Re:Well, that doesn't matter

[heffrey]

There are no comments bashing Microsoft at all so far, let alone claiming they should retain VBA. Can you read? There are loads of comments bashing MS that pre-date grandparent.

Re:Well, that doesn't matter

[Hatta]

We bashed them when we read that they wante to drop it. let's bash them because they don't. Hell, this is Slashdor, isn't it?

No, it's not.

Re:Well, that doesn't matter

[Anonymous Coward]

I'd love to know which Slashdot you read where pro-Microsoft posts get modded up consistently.

SF Zoo tiger attack victims were high and drunk...

[Anonymous Coward]

Why am I not surprised to learn that wed and alcohol were involved in their decision to taunt the tiger. I guess the two survivors will never make that mistake again. I can't say they didn't deserve their fate. The dead one should get a Darwin Award.

http://www.breitbart.com/article.php?id=D8U85K080&show_article=1

Mac users only eh?

[Paranatural]

VBA Will continue to be supported by future versions of Office for Windows, just not Macs. Also, no more new Licensing. Really, to me, it sounds like Microsoft is about to do something with VBA it doesn't want Mac users to have right after launch.

Conspiracy theories aside it could just be they are going to keep the support for Legacy systems but don't want to keep up with that junk for mac users, maybe it's harder to implement on the back end?

Re:Mac users only eh?

[cnettel]

VBA relies on COM and parts of the original (up to VB6) VB engine to do its job. The Mac layer was based on a COM implementation on Mac. To continue the licensing scheme, they would have to maintain the complete library and eventually port it to 64-bitness. Just keeping the bits needed for Office can be simpler. At least, they won't have to maintain an external-product quality interface to the host application developers anymore. VBA support in a future Office release might be done through process separation and a separate thunking layer (moving all the COM servers out of the actual process and making those talk to the actual Office applications through the new API), or translation on the fly to a new environment. Keeping support doesn't have to mean that the current environment really stays there.

Re:Actually, no. Did you RTFA before submitting?

[HiredMan]

VBA is gone from Office for the Mac and VBA developers is closed. Microsoft is acknowledging that both these "clues" that made people conclude that VBA in Office was going away are true - but they contend that VBA in Office is not going away.

"The facts you cited are right - but your logical conclusion was wrong. We're Microsoft and we are not bound by logic."

Basically.

=tkk

Re:Actually, no. Did you RTFA before submitting?

[Richard_at_work]

The entire article is thus -

Following MacWorld earlier this week, there has been some inaccurate information circulating online regarding VBA support in Office for Windows. While it's true that VBA isn't supported in the latest version of Office for the Mac and the VBA licensing program did close to new customers last year, we have no plans to remove VBA from future versions of Office for Windows. We understand that VBA is a critical capability for large numbers of our customers; accordingly, there is no plan to remove VBA from future versions of Excel.

Point by point:

1. VBA isn't supported in the latest Office for Mac
2. VBA isn't being licensed for third party inclusions anymore
3. There are no plans to remove VBA from future versions of Office for Windows
4. No plan to remove VBA from future versions of Excel

So, its not supported for Mac, and new developers cannot include it in their products, but it will remain supported in Office for Windows apps. Not sure what blog you were reading!

Re:Actually, no. Did you RTFA before submitting?

[Westley]

Where exactly did you read that it was no longer supported? The articles states that it's no longer supported *on the Mac*. That's not the same thing as "no longer supported".

The way I read it, the message is "If you're on Windows and depend on VBA, don't worry - you can still upgrade to the latest version of Office (for Windows). That said, we're strongly discouraging future VBA development."

How about using .Net?

[mallardtheduck]

What I would like to see would be a .net based macro system in Office. Something where we could write macros in VB, C#, Python, or any other CLR language.

Since .Net has built-in support for different trust levels, code signing, etc., security should be more manageable.

Most of the work is in fact already done. The Microsoft.Office.* hierarchy already exists in .Net, all that is really needed is a way to embed .Net code in MS Office documents.

Re:How about using .Net?

[Shados]

It won't be long... I mean, SSIS's script components already use VB.NET (and in the next version can use more languages), so the scaffold is already there.

Re:How about using .Net?

[andy9701]

Isn't that what Visual Studio Tools for Office does? I've never really looked into it much, but my understanding was that it was a .NET replacement for writing Office apps with VBA.

Re:How about using .Net?

[Anonymous Coward]

What I would like to see would be a .net based macro system in Office. Something where we could write macros in VB, C#, Python, or any other CLR language...all that is really needed is a way to embed .Net code in MS Office documents. Look no further: VSTO (Visual Studio Tools for Office) has been around since 2003. It lets you do extensive design-time and run-time customization of documents and templates for all the Office apps. You can hook events, create menus, buttons, ribbons, and custom task panes that can do anything .Net can do (including using WinForms and WPF controls). You can also write application-level add-ins for Outlook, Excel, Word, PowerPoint, InfoPath, and Visio. The default project types are VB.NET and C#, but you can reference assemblies written in any CLR language.

VSTO is a free add-on for Visual Studio 2005 and built into 2008. All you have to do is create a document customization or add-in and your .Net code is attached in a DLL. There is also a ServerDocument object you can use the apply and remove customizations for existing documents and templates, and a data caching model so you can preserve the state of your objects right inside your documents in case you aren't backended by a database or an external file. There is even full F5 run and debug support for all of the projects. This has made Office development basically work like any WinForms or ASP.NET project, which is pretty amazing considering the relatively sorry state of VBA and COM automation you had in the past.

Since .Net has built-in support for different trust levels, code signing, etc., security should be more manageable. Security is more manageable because you can either use the very granular Code Access Security model or the ClickOnce sandbox, depending on your deployment requirements. If you really are interested you should check it out. The MSDN support forum is extremely active, and there are no fewer than 20 VSTO books available.

Most of the work is in fact already done. The Microsoft.Office.* hierarchy already exists in .Net FYI, Microsoft.Office.* is just for external COM automation of the Office programs through the programmable interop assemblies. This is what you get when you check ".Net Programmability Support" during setup in Office XP or later. It's for manipulating in-memory documents or opening and automating the main program interfaces. Very basic.

Re:How about using .Net?

[nickruiz]

I don't see why they wouldn't just bundle Visual Studio Tools for Office (VSTO) runtime within Office 2009 and provide the opportunity to use that or OOXML. I think I would have more confidence in a VB.NET macro written by someone who doesn't have a clue about object-oriented development, rather than hang on to insecure and deprecated technology. Careful what you say about writing the code in any CLR language. I doubt that anyone would like to see a macro written in a .NET rendition of COBOL or Fortran. LISP wouldn't be so bad, though. ;-)

Mod AC Up

[mpapet]

Informative, Insightful, Funny. Just pick one.

A limerick

[kcbanner]

Once there was a language called VBA,
Microsoft said it was here to stay,
First they denied it, the community despised it, we can only home its deprecated.

Re:A limerick

[Dephex Twin]

There once was a poet named Banner
Who composed in a god-awful manner
With hardly a rhyme
Or awareness of time
He'd do well with some Lear and a scanner!

Still...

[Nom du Keyboard]

Still, even if they keep in in Windows Office, there's no question that it's gone in Mac Office 2008, and that's a huge monkey wrench in mixed business environments. While I'm sure that the Microsoft "solution" is to just have you dual-boot into Vista when you need to run VBA on your Mac, this seems to clearly be an attack on Apple's recent success, and could be a deal-breaker in a significant number of environments.

Or Mac users could refuse en masse to "upgrade" to this "downgrade".

Oh well.

[jrothwell97]

VBA sucks anyways. And OS X users get AppleScript which is far more efficient than that awful mess in Office.

Re:Oh well.

[thePowerOfGrayskull]

...which is great until they want to share a document w/ macros with someone on Windows...

Re:Oh well.

[jrothwell97]

Yes, that is a limitation of having people using Windows on the network...

...all the more reason to wipe Windows off it and install Fedora or Ubuntu...

Re:Oh well.

[thePowerOfGrayskull]

Or mail a document to someone at another company... I mean, I agree, it would be great to wipe out Windows and Office universally... but until that happens, we really are more or less stuck with the need to have interoperable macros in a business environment.

Re:Of course,MS is catering to their real customer

[samkass]

Looks like MS may be crippling the Mac version to stop enterprises from moving on from Windows.

Vista needs some competitive advantage over MacOS X, I guess. Since OpenOffice supports it, though, I suspect most Mac users would rather give up MS Office than MacOS when possible. Considering the Mac is growing 2-3x the industry rate, tying Office to Windows in this manner is just Microsoft nailing one more nail in their own coffin.

Boggled

[samael]

Has anyone actually read the original explanation for why Office 2008 isn't getting VBA?

http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/

Which makes it very clear that there are good technological reasons for dropping it. Or, at least, it's going to be such a huge amount of work to bring it natively to Intel that it's not worth it to MS.

I mean, sure, some people at MS may be happy about it vanishing, but it doesn't sound like a conspiracy to me...

Re:Boggled

[SpaceHamster]

Which makes it very clear that there are good technological reasons for dropping it. Horseshit. His post says, at great length, that they didn't want to write a whole new jitter for the mac-intel platform. Fine, sounds tough. Wouldn't interpreting the VBA opcodes be worlds easier (and more future-proof)? Or just running the good ole legacy vba engine under a mac-ppc emulator?

The real problem is that the company has lost its consumer market lock-in and is desperate to staunch Apple uptake in the enterprise, and removing VBA support is as close to a guaranteed deal breaker as they'll ever get.

Re:Boggled

[treeves]

I'd vote for this being the right answer but I didn't see the evidence that enterprise is switching to Apple in the first place.

Re:Boggled

[Anonymous Coward]

Apple users: See what happens when you trust Microsoft and start building programs and extensions around their products?

I somehow don't believe it

[pizzach]

It might take a few years, but I believe VBA is on it's way out. It's just Mac developers tend to jump the gun a few years early. (Dropping serial ports for only USB, dropping the floppy drives, dropping the cdrom bay...)

If VBA is actually here to stay, I say the telltale sign will be if VBA support is included in the NEXT version of Mac Office X. That is called backtracking.

My thoughts in lyrical form

[Philotechnia]

Sung to the tune of "Chocolate Rain" by Tay Zonday
http://www.youtube.com/watch?v=EwTZ2xpQwpA
(If you don't know, now you know)


VBA
So many people writing code in vain
VBA
Debugging apps is really quite a pain

VBA
Microsoft says it will not support
VBA
To C#, functionality we'll port

VBA
No rhyme or reason to deploy this mess
VBA
A seasoned coder really could care less

VBA
Slashdot will flame Microsoft either way
VBA
Now I'm confused why it is here to stay

May Deny But Intentions Are Clear

[littlewink]

VBScript is the core language of VBA and was the only extant language omitted with the release of .NET. Microsoft's language development groups didn't want to support the language - classic VB and VBA were held to be hacks. So it was proposed that VB/VBA be killed.

In a most unusual display of synchronicity, Microsoft's marketing group also wanted VBScript killed because:

• it was a "free language" - VBScript & ASP enabled web development in Notepad - selling Visual Studio development tools was next to impossible with a free and simple alternative available.
• a belief that millions of VBScript/ASP developers using Notepad would buy into the new .NET development environment tools. That is, greed.

What instead happened is that the millions of VB and ASP developers, seeing their toolkits and production code abandoned and marginalized by Microsoft, abandoned IIS, ASP and VB en masse.

Today .NET is on life-support: half a decade after the release of .NET there remain more .ASP pages on the WWW than .ASPX. Microsoft's latest release of .NET development tools presents the enterprise buyer with a more confounding variety of labels, choices and courses than has been available since the height of IBM's enterprise supremacy, none of them any better than their earlier products Notepad and VB.

Re:May Deny But Intentions Are Clear

[cyber-vandal]

Is it not possible to replace VBScript with JScript?

Re:May Deny But Intentions Are Clear

[shutdown -p now]

Today .NET is on life-support: half a decade after the release of .NET there remain more .ASP pages on the WWW than .ASPX.

Source? I see plenty of .aspx pages daily, and only occasionally stumble onto a plain .asp.

On a side note, have you watched the number of .NET vacancies posted in the last few years? It's not exactly falling, you know. Quite the opposite. For new product lines being started today, .NET/WinForms is essentially a default choice for a Win32 GUI application, and one of the major options for any web app. Also, MS comes out with more and more .NET-specific APIs and frameworks: WPF and WCF come to mind immediately. "Life support"? You may wish it, but things aren't like that at all.

If it's 'here to stay'...

[theurge14]

...then why was it just cut out of Microsoft Office 2008 for Mac? If we Mac users are supposed to use Applescript instead of VBA, then where are the Microsoft supplied tools to convert VBA to Applescript? Does Microsoft not care about their customers enough to ensure compatibility between their most recent Office release?

Re:If it's 'here to stay'...

[sherriw]

If you aren't running your MS sofware on an MS operating system, then you aren't a real customer. Heh.

We need a new mod category...

[Anonymous Coward]

.. of "Insightfully Funny" or "Not Completely Sarcastic" or something like that.

Embrace, Extend, Extinguish

[Foerstner]

Or, at least, it's going to be such a huge amount of work to bring it natively to Intel that it's not worth it to MS.

At one time in the past, Microsoft considered it worthwhile to port VBA from Intel and Win32 to PowerPC and the Classic Mac Toolbox.

Today, it's too much effort to either 1) update the existing VBA engine or 2. Replicate the previous clean-sheet effort. Despite the fact that the Mac is growing in market share, and Office sales are very healthy--something that could hardly be said back in the late '90s when VBA was brought over.

I assure you, moving VBA from Win32+x86 to Classic Toolbox + PPC was a much bigger technical challenge than it would be to do the same on the modern Mac architecture. There is only one reason why Microsoft is no longer willing to do so. VBA is established and is ready to serve its purpose as a mechanism of lock-in.

Re:Embrace, Extend, Extinguish

[Your.Master]

What if, hypothetically, they are not removing VBA from Windows Office but are deprecating it? Let's follow this idea along. This means that VBA scripting is no longer encouraged on any platform and has a limited lifetime -- how limited? More limited than it was for the original port, anyway.

Further, Office sales being healthy anyway seems like a good reason (not good TECHNICALLY, but good in business terms without being morally questionable) to me that they don't feel they need to port VBA this time.

Re:Of course,MS is catering to their real customer

[Keeper]

Or maybe there are other, more reasoanble decisions, behind dropping VBA from the mac version? http://www.schwieb.com/blog/2006/08/08/saying-goodbye-to-visual-basic/

And secondly, are people on slashdot REALLY complaining about VISUAL BASIC going away?!?

Re:Of course,MS is catering to their real customer

[Anonymous Coward]

Uhhh, already happened dude. Office 2008 is now for sale and is stripped of all VBA. They are telling people to macro in AppleScript (puke).

VBA! Yay!

[Anastomosis]

This is exciting news! Wait, the only VBA I use plays my copy of Final Fantasy Tactics Advance, nevermind.

Re:Actually, no. Did you RTFA before submitting?

[BobMcD]

The articles states that it's no longer supported *on the Mac*. That's not the same thing as "no longer supported". RIIIIIIGHT. Cause NOBODY owns a Mac. ;)

(Not on the Mac)+(No new licenses)= Dead

They won't put a gun to your head, or otherwise force you to remove the documents from your computer, but rest assured that this offering will soon be cruising down 'sunset' strip.

Re:Actually, no. Did you RTFA before submitting?

[Westley]

Yes, people own Macs. But not *everyone* is running on a Mac, are they?

There are plenty of places where the impact of VBA not running on a Mac will be zero. The fact that it's not supported on Macs doesn't make it dead at all.

Re:Actually, no. Did you RTFA before submitting?

[BobMcD]

You are ignoring the second factor. Whether on purpose or by mistake remains to be seen, but the two of them together create context.

That would be suicidal in Excel case.

[jacekm]

VBA in Excel case is a major advantage Excel has over most competitors. For many engineers capability to write custom programs using popular programming language within the spreadsheet makes Excel the spreadsheet of choice that has no viable competition. This drives rest of the company and cooperating suppliers into the MS Office as a standard. Dropping VBA would be in case of Excel poor decision. Such spreadsheet would lose support it has between technical professionals today. On the other hand I haven't seen much use of VBA in the rest of the MS Office applications. JAM

Re:Actually, no. Did you RTFA before submitting?

[Westley]

Okay, the second factor: no new licences.

It's far from uncommon for a company to stop selling licences for a particular version of software, but to keep supporting it. That certainly discourages green-field development and should encourage migration to an alternative solution over time, but it's not the same as the solution no longer being supported.

Jon

VBA Went Too Far

[cjb110]

Personally I think VBA went too far, it wasn't a simple macro language.

Which meant it was ripe for abuse and overuse. Too many companies have important, business critical functions/logic entombed in Excel 'macros', or Access 'applications'.

If I've understood MS's intentions, they want all office programming to be done within .net, which is fine. But I think they should then 'freely' distribute an Office specific version of say C# Express. I can't see many customers being happy if they forced to also buy full Visual Studio versions if they want to convert their Excel/Access apps, esp not the SMB's.