So tell us what you want, what you really really want!

There are very few corporate customers which are purely Mac shops, therefore cross-platform compatibility is vital. Furthermore, the cost of rewriting VBA code adds unjustifiably to the upgrade cost, even if your alternative Applescript solution manages to do everything that VBA did. (From this blog entry, it looks as if you are ackowledging this to be unlikely.) Therefore dropping VBA from Mac Office essentially kills the product for the corporate market. Companies will stick with Office 2004 or move their Office desktops across to Windows. They are not going to be happy to pay you for the privilege of being forced to rewrite all their VBA code.

Of course, not all customers are corporate. But individual users will generally only buy Office with a new computer - I suspect relatively few individuals will upgrade Office on an existing computer. Office long since reached (and passed) the point at which it was good enough for individual use. Therefore, just about any relatively recent version of Office would do for individual users, and so there is little competitive advantage in making a newer version for them.

So, with the loss of VBA ruling out most corporates from upgrading their copies of MacOffice, and individuals not buying upgrades, I wonder from where the you expect to get the additional sales that will justify the development costs for the next version.

Has Microsoft considered not bothering with a new version of MacOffice at all and redeploying the development resources to something that offers the prospect of sufficient sales to justify the use of them? You could continue to offer security patches, and you could make file filters for the new XML format (as is being developed for older versions of Office for Windows) and leave it at that.

VBA code that I provide in templates for my customers? Just take a look at the VBA code examples at http://word.mvps.org for some of the more common things that Word customers ask for. Just about every template I create has about 2000 lines of VBA code in it.

There were comments in the last days that sugested you to replace VBA with RealBasic. Is this possible?

There are two lights at the end of the tunnel:

- Office 13, which might just slip in under the agreement if sales of Office 12 disappoint

- Parallels, or another “Red Box”. The funny thing is, this probably won’t make much of a surge
in Office for Windows sales at all, since so many places that have the ‘xplat’ issue are site-licenced.

(Bundling Office 2004 with Office 12 is a great idea, by the way. Who really loses here?)

I’ll just finish by mentioning how I use VBA. I literally learnt how to use it in two days while off sick from work because I had to hack up a workaround and got bored in bed. Which means I really don’t know VBA that well, beyond what I gleaned off a few Google searches … but then how many others are like me?

The point is, I barely use VBA for anything more than an unlimited-row lookup substitution — a function that I was missing in Excel due to a (pathetic) 7-deep nesting limitation. Actually fair’s fair: It’s a bit silly to have to nest Excel functions more than 7 times, but then there doesn’t exist anything like SUPERSUB(string,substr-from-column,substr-to-col) in Excel either.

Hmmm, I guess that means if a SUPERSUB function existed in Excel for Mac, then it would be equally useless in Excel for Windows as an AppleScript would be.

Personally I hope some clever third party is rubbing their hands together and looking to provide some kind of VBA AS translator.

CK.

Once again I’m very glad to see you blogging about this stuff.

When I heard about the demise of VB on the Mac, my first thought was whether it would be to the exclusion of any scripting mechanism. I’m really glad to hear you’re working no building up the AppleScript support. The few times I’ve used VB for office on the Mac, it’s been a workaround to do something that reasonably should have been doable in AppleScript. It felt like a hack to do it in VB.

I’m concerned about the cross-platform angle. The idea of files that “work a lot better” on a PC doesn’t sound good to me, and it must also cause anguish in the halls of MacBU. But I think you must have based your decisions on statistics more meaningful than my gut instincts, so I hope most Mac Office users will not be too disappointed.

It’s probably obvious but please remember to present a dialog to the user informing them of the limitations, when VB is present but not runnable. It would be worse for the user to simply see things not behaving the same as on the PC.

As a brainstorming idea: what do you think about allowing Mac users to package AppleScript into the file as VB can be done from the PC? I’m not sure how common it would be for a document author to include “functionality similar” scripts for each of the platforms, but having the option as an out for very serious shops might be an appropriate fallback position. I guess this would require some coordination with the Office PC team, which I’m assuming you must already do quite a lot of.

Hi,

I appreciate that you’ve looked at all possible options and selected the most pragmatic one. The one thing I would like for you to address is the option for third parties to extend Office 12’s scripting support. Will this be possible?
I’m thinking specifically of RealBASIC btw.

Where Apple script is concerned, Office is now becoming an increasingly better citizen of the Mac world by incorporating Mac OS X specific technologies. I suppose that full VBA feature parity with Windows is a pipe dream. In this respect, Apple script would definitely be a more robust platform for scripting Office Mac Applications. I’m also hoping that because of the move to Mach-O, Excel will be able to use the native ODBC drivers and not require a third party add-on like 2004.

Thanks again for being so open!
Shahram

What I want to know is how many users actually use VBA where it is a deal breaker to not have it anymore? What would that percentage be? I would be guessing that it is very small compared to the total users.

Robert, it wouldn’t have to be a dealbreaker for a large proportion of users, it would only have to be a dealbreaker for at least some users in a large proportion of companies or other large organisations who are customers.

Large orgs are not going to tolerate mixed installations, their IT departments have trouble enough already, so if there is a mission-critical VBA app somewhere that will break, it will abort the entire upgrade rollout unless and until it can be rewritten.

I would guess this scenario will apply to many or even most corporates. That is why I think the next version will completely bomb in the corporate market unless the VBA decision is reversed.

we use vb macros in a uni maths department to process the marks from dozens of examiners, who are on computers that range from mac os 8.6 to windows xp. the vb code is thousands of lines long, does tonnes of calculations to calculate the relative difficultly of different papers. You may find making VB run on Intel time consuming, but I would find rewriting this code much harder. i am a self-taught programmer, and i do not want to have to learn applescript. please please please please please please do whatever it takes to get VB on Intel, or i will cry.

how about c# or .net?

Karma

Regarding C# or .Net, some may recall Microsoft’s open source Rotor project for FreeBSD which was a CLR implementation. So MS has at least one Unix CLR implementation that it could use in Mac Office.

But apparently Rotor wasn’t very good. Mono is, however, open source and pretty good. I don’t know if MS would be happy taking Novell-developed code or not…

The Mac version of the Imeem client is partly built using Mono; they obviously think it is production quality.

What do I really want? It’s actually quite simple:

- Word
- Excel
- PowerPoint
- Access
- Messenger

That are fully cross-platform compatible. I want the same functionality on the Mac that I would have on Windows. I understand that the APIs are completely different but you guys are smart enough to come up with a way of bridging that divide. After all, Apple was able to come up with Quicktime for Windows and surely Windows didn’t have the Mac’s APIs then or now.

I want the functionality of Office with a Mac interface, touch and feel.

BTW - I’ve been trying OpenOffice and in addition to being pretty comparable to MacOffice, it’s amazingly fast on both my PPC and x86 Macs. Thus far, it’s displayed my documents faithfully to the MacOffice version.

Dude: Porting .NET would be even more work. Like, a *lot* more, as I understand it.

(And note that the VBA here is not VB.NET; if they did somehow port .NET to OSX, VB.NET wouldn’t be much if any harder to manage there than C#, at least as far as I understand it, but I don’t work at MS and I don’t know the internals.

In fact, they might both be free once you had .NET and a cross-compiler to get things self-hosting. That is, if the VB and C# compilers are .NET themselves; I don’t know if .NET is self-hosting yet.

It’d be double-cool if Visual Studio was, but that would also require porting System.Windows.Forms to OSX, and… Jesus, I don’t even want to think about what a cluster**** that would be.

I’d love if it happened, though, since then the code I get paid to write would work on OSX as well as Windows, and the Mini is actually a fairly compelling form-factor for our market…)

I guess the overall lesson here is one of open data format compatibility. The original drop-VBA decision comes about because the original implementation code is over a decade old (indeed, some of the code in Mac Office is older than some of the people working on it). It’s too old and too awkward for the MacBU to update it for the new Mac architecture.

Any company or user who invests considerable effort and time in building VBA macros (or AppleScript macros, for that matter) is, consciously or not, buying into a proprietary language that may or may not become obsolete in the future. Whether VBA in Mac Office gets updated is a decision that must rest entirely within Microsoft, because the company owns the language. Similarly, what AppleScript is able to do is something entirely under Apple’s control.

When you build workflows based on that, you’re taking the risk that, at some future date you cannot predict, the language won’t be supported anymore. That’s what’s happening now.

So, as a non-developer, my suggestion and question is: is there a way to use *open standards* to continue to support scriptability in Mac (and Win) Office without relying on either Apple or Microsoft in the distant future? Is there some sort of scripting environment related to the OpenDocument standard that might persist into the foreseeable future?

Is this just a pipe dream?

I want precisely what Neema Agha above wants.

Specifically, we use a VB app called Wordfast. It is the only translation producivity tool I know of that works both on Windows and the Mac. It’s a brilliant little app. Having used it for years, we have built up an enormous data base of translation memories that keep us competitive. We use it mostly in Word and sometimes in Excel. Unfortunately, it doesn’t work very well in Powerpoint on either platform, but the developer is working on that. For us, Office for Mac without VB, which enables us to use Wordfast, plus some specific Word macros sent to us by our clients, is a deal-breaker. Please find a way to keep VB, to make it better and keep it compatible with Office for Windows.

I agree that being able to use Windows docs using VBA is what’s going to be key here. If there’s someway to get them to translate over using REALBasic, Applescript/Automator, or something, that would be great.

What’s most frustrating is that I just don’t get the feeling that MS is doing anything beyond plain maintenance for the Mac side. (And when I mean MS, I mean the MacBU’s bosses, not the unit itself which I think does great work with what they have.) You would expect the largest group of Mac developers in a company outside of Apple would have more to show for it, you know? If you kill something, there should be a backup plan in place: no more IE because we have Safari (that’s fine), no more Virtual PC now that the Intels are out (also makes sense), Flip4Mac replacing Windows Media Player (not a one-for-one exchange, so I’m not keen on that, but better than total abandonment), but VBA just gets plain ol’ dumped.

In short, I’m not happy with your corporate overlords. MS has been taking more away from Mac users than they’ve been putting in. And if you’re having a staffing shortage, they should be stepping up to the plate with better incentives to do something about that as well. I don’t want to be told that “as always, cross-platform compatibility remains a top priority”: I want to see the proof for myself.

Just a quick note, Windows Media Player for Mac was done by the Windows Media division in Microsoft and NOT the MacBU. Complaining about the WMP9 drop here is no use. The MacBU was never in charge of it.

I appreciated your candor about how difficult it would be to port to Intel. I would submit that no one really wants you to spend time building a new editor/compiler/runtime/forms interface, but rather people want a cross-platform API that allows them to write code once for both Windows and Mac office. How about working on a javascript implementation of the API? Maybe MS would be willing to spare some Win Office folks to work alongside you. There’s already a javascript engine for MacOS, so now you need to implement only the office hooks, which is what you do best.

Its always painful to take away features, but you really are hurting some businesses with this one, and threatening the existence of the MacBU. Wouldn’t you agree that the less cross-platform compatibility you have, the less likely people are to bother using your product, since that’s its primary niche?

Maybe you could get some help from Open Office? They’re working on a VBA implementation (an obvious dig, but not altogether without substance):
http://wiki.services.openoffice.org/wiki/VBA

Just a quick question for those who know more about this stuff than I do.

I rely on two add-ons to Word, namely Mathtype and Endnote. As best I can tell both of these use a fair bit of VB Script. I’m guessing this decision is going to make the lives of the developpers of these apps a fair bit more difficult.

Does this seem plausible? If (big if given how long I waited for the OSX port of Mathtype) they decide to update using applescript, will I still be able to exchange documents with Mathtype documents with Windows users?

Any informed speculation would be much appreciated.

Thank you for writing about the reasons why VisualBasic will not longer be supported on Mac Office. I am a beginning VBA developer on Windows, and noticed that even the most basic of scripts had problems running on Office 2004 (mainly because of the ActiveX controls rather than Forms).

Nevertheless, I certainly hope that there will be something done so that people who buy the Mac version of Office will be able to run VBA. Personally, I would be a much happier customer if Mac Office shipped with some kind of Visual Basic platform - even if it only ran on Windows.

Thus, I would be happy if Microsoft/MacBU could include Word/Excel 2007 for Windows with the purchase of Office:mac at no/minimal additional cost. The reason is that VBA is so common that I would still need Office 2007 for Windows - and it is very difficult for me to justify buying a copy of Office for Windows and a separate one for Mac.

If I had to buy separate copies of Office for Windows/Mac, I might just get Office for Windows, and iWork for Mac - and just stick with Office 2004.

It might even make business sense for Microsoft to include Word/Excel 2007 for Windows with the Mac version, too — because it would probably increase purchases of Windows licences.

Hopefully this is specific and actionable — maybe not by yourself, but if it could be raised with those responsible for decisions regarding marketing/selling/etc.

Maybe the solution to this “Impasse”, is in the wild:

You could try something like putting a bounty for it, “Microsoft will pay “x” amount to an individual or a company that could satisfy this need”

Or something like that.

I have never ever used a macro, so I’m not in pain like so many others, but I love Office so it worries me that an issue like this could be the beginning of the end for this app.

Hi there,

You know, after allowing all this to sink in for a bit, I really think you’re doing the right thing, with a few qualifications (which I’ll get to later).

Honestly, I personally don’t write VB. I don’t know how, and I’m not that interested in learning. I have been known to script Excel with Applescript and would be thrilled if its object model and scriptability were improved.

However, at school I quite frequently receive Excel worksheets with VB embedded in them. These take the form of chemistry calculators, helps for Calculus homework, or something as mundane as a class schedule calculator. The thought of no longer being able to use these at all sickens me. But my University has good open access computer labs, so all is not lost for me (until I graduate and enter the workplace, that is).

Now, here are my reservations about your decision. I think cross-platform scripting needs to return to the Mac, eventually. Make this a temporary situation. Devote a few resources to it, not enough to significantly hamper other efforts. Rewrite it in a higher-level fashion, or whatever makes sense. Like I said on the last post, I don’t care if it takes 3-5 years, but from my outsider’s perspective, it has to be done.

If it is really true that “if you can do it in VB, you can do it in Applescript”, then how about a cross-compiler/interpreter? Translate the VB into Applescript (or raw apple events, even). You could even do it on the fly. This seems feasible to me, though I really have no idea if it’s practical. If it is, it seems like a good compromise to provide compatibility.

Once again, thanks for being forthcoming - were it not for your posts, I would still suspect MS of deliberately attempting to marginalize the Mac, especially in the Enterprise that has for many years been almost exclusively its turf.

I’m not a power user or anything, but I’d guess that I’m pretty close to an average mac user in what I want out of my programs. I want interoperability. I quite enjoy Mac Office currently & upgrade soon after a new version comes out. This is in stark contrast to my earlier habits. Why do I upgrade? To be honest, Mac Office has done almost everything I need it to do for years. I upgraded to office x because it was OS X native. I upgraded to 2004 only because it was the most current & most compatible version with the most recent versions of Windows Office. I was planning on upgrading to the next version of Office when it came out, for the sake of compatibility with the new versions of windows office. That’s not the case any more & actually 2004 will be more compatible than the next version (2007?). I remember well the days of Apple bundling dataviz’s translator with macs to read windows files & translating them back & forth. It was a real hassle & you had to cross your fingers that when you sent a file, people could read it & when they sent you one, you could read it. Now, aside from small issues (font stuff & PP mostly) Office files work great on either platform. I can create them on my mac & send them to windows using friends or vice versa. I can’t remember the last time I had a major problem with an office file. My wife’s boss recently sent her a microsoft works file that we tried to open on our macs. We couldn’t do it. In the end, we had to go to a friend’s house & use a windows machine to translate it to windows word & then it transferred fine to the mac. This is the kind of stuff I fear. The file that we got was something that we needed immediately. It was last minute, working on a presentation the night before it was to be given (no we couldn’t have planned better, the project came up last minute.) Yes I know that it was works, not office, but this is the kind of stuff I fear in the world of differing feature sets for Mac & windows office (and yes I know that they currently have differing feature sets, but from a practical standpoint, they are close enough that MOST business users won’t notice a difference. Removing VB would change this)

I recently helped create a spreasheet for my wife’s boss to help track hours/sales/calls/etc for each person on the team. The file was originally created on a PC (and made use of VB), then sent to me where I finished it & sent it on to the boss, who was able to use it on his PC. Everyone on the team is able to use the file on their wondows PCs, as is my wife on her mac. I don’t want to have to worry in the future about situations like these. Will they work, won’t they? With differing feature sets, this becomes a distinct possibility. I use VB only a tiny fraction of the time, in a tiny fraction of my documents, BUT when I need it, I need it.

thanks for the interoperability you have given us in recent years.I’m sure ti was a lot of work but it has truly been a blessing (PP is still a bit of a PITA, but that’s life) & is probably one of the major behind-the-scenes reasons for apple’s recent resurgence. Please keep it that way.

BTW, if I had to choose between your two pillars, mac-like & interoperable with windows, I would lean towards the interoperable side. Obviously I want my programs as mac-like as possible, but the farther you go down this road, the closer you get to iWorks. That is the ultimate mac-like program. While I like it & it’s a great program, I buy office instead because it’s interoperable with my windows buddies. As soon as a .doc or .xls file becomes anything less that standard (Is that a mac .xls or a windows .xls file) then office becomes that much less desireable.

I’ve only read this blog entry and the last one (and almost none of the other comments), but allow me to oversimplify the entire issue and provide a few random thoughts:

1. The original implementation seems to be far too “deep”, but perhaps it was written this way for memory and performance reasons “back in the day”. I also don’t know what your minimum configuration is for the next release of Mac Office, but it seems to me that a higher-level scripting approach would be much easier to implement.

2. I’ve never written a line of VB (inside Office or out), but it occurs to me that most of what you’d want to do in VB would be (a) to modify the document and (b) to perform some calculations, string manipulations or other non-document-specific variable manipulation. With JavaScriptCore available today through the open source WebKit project, perhaps it would be possible to write a VB-to-JavaScript translator wherein objects, functions and properties would be bound to the Office DOM on an as-needed basis to provide the requisite functionality.

3. Instead of using JavaScriptCore, perhaps VB code could be “compiled” into ObjC runtime calls, akin to what F-Script does. I think this would be more work than using JSC, though.

4. I’m guessing there aren’t any good test suites that could be used to test a brand new VB implementation in Mac Office. Such a pre-existing test suite ought to reduce the number of man-hours by quite a bit (assuming a large portion of the original estimate included manual testing of a brand new VB implementation). Even an external VB test suite that could be internalized on the project would be helpful.

5. Finally, it’s unfortunate that this part of the Mac Office project couldn’t be open sourced so that the people who want it most could work on it. Coordinating such a project would probably take more time away from your project to ensure a high quality of code, although the benefits are great. (Just ask Apple’s Safari/WebKit team.)

Dave

I can buy the argument that it’ll take time and you don’t want to delay the next version. Fine. Can you release the next version without VB and work to have it back in as a feature in a later version… or even as a future update to the next one? I spent several years teaching myself VBA to create software for my school district that creates, modifies, and customizes about a dozen different forms we need. It’s a large project that includes a lot of code, autotext entries to manipulate, and a toobar used to launch certain features (more marcos). I work in a cross-platform school district so it’s been great being able to write a single code and have it work on any machine the template is installed on. Quite frankly, it was beautiful to see how well it worked on any machine in the district.

In order for this software to survive I see that I’d have to completely rewrite the Mac code (learning Applescript along the way) and then keep 2 versions up-to-date. I simply can’t afford the time do that since my time on the project was essentially “donated” (I’m not hired as a tech person, I was doing this to learn programming and provide a service). This move will essentially kill my project…

But it could survive skipping a single version of Mac office knowing the template would run on future versions.

Steve B.

I agree with the last poster, Steve B.

Office Mac skipped a version in v7 (Office 95) and v10 (Office XP), IIRC. When I think that my company only just upgraded from Office 2000 to 2003 (v9 to v11), then I think a few short years living with a fully OSX’ified v11 will work … and some kind of low-key press release later this year will assure MacBU’s fortunes.

Shortcuts that MIGHT work:

- Replacing the VBA/VBE/Forms with something that only interprets what’s embedded in a Windows file … interpreter speed is not an issue!

- Doing a long survey of VBA users and seeing what features they REALLY use, and seeing if you can develop a solution that fits MOST of them, following the 80/20 rule … a previous poster commented how “deep” VBA seemed, and yeah, it’s like Middle Earth in there!

Of course, such a shortcut would involve some Stevenote-style demonstrations, and asking people to walk up to an expo demo booth with their own documents to try it and see. They might likely have documents that contain VBA they only use, and were written by a developer on Windows long ago. And going through all the arguments from the last week all over again. But hopefully then with more people defending the move?

CK.

I’m surprised you didn’t consider getting the main office team to rewrite VBA in a more modern and portable style. I’m guessing it’s because it would a) probably subtly break compatabilty with existing scripts and b) still rely on win32 apis, but it’d be nice if you could confirm this.

The main concern of small businesses is that they be able to hire somebody else down the line to maintain my code. They may need two changes a year; it’s not reasonable to have somebody on staff, and it’s too risky from their perspective to assume that I will always be around to do things for them.

This means they need a language which many other people are using. There are far fewer AppleScript developers for hire than VBA developers. They’d have no idea where to even start looking for one, and they aren’t too thrilled with even remembering what language the stuff is implemented in.

From their perspective, game over: In order to keep the old VB macros, they will avoid upgrading for five years or more if necessary. They’ve done it before for lesser reasons.

What I’d really like to see in the long run is a new, cross-platform scripting language for Office. Deprecate VBA and keep it for backwards compatibility. Clearly this would require much greater cooperation between MacBU and whatever part of Microsoft is responsible for Office-for-Windows, but if that’s what it takes, that’s what it takes. Your explanation was very persuasive, but it keeps coming back to “we can’t do this because it would require working closely with the Windows team on an ongoing basis”, and that’s not a technical problem, it’s a business one - so solve it.

Well I’m glad I never learned VBA and stuck with XLM macros!
So, what is the future of XLM? Will XLM macros still be writeable in the next version of Excel? How about a resurgence of my fav– er, first programming language?

James said “I’m surprised you didn’t consider getting the main office team to rewrite VBA in a more modern and portable style.”

Quite frankly there is no chance of getting Microsoft to rewrite VBA in multi-platform way. If they did so, it would give the lie to their claim that VB6/VBA couldn’t be compiled to the .NET platform. Just not going to happen. Too much pride at stake in the Visual Studio group.

In fact, this whole problem ultimately has at its roots the VB6/VB.NET fiasco of a few years ago, when Microsoft took their eye off the ball with regard to forward compatibility, and shovelled dozens of unnecessary language and syntax changes on top of a very small number of essential technical changes in the platform (chiefly the new mechanism for handling object destruction). Had Microsoft taken proper notice of customer feedback at the time, VB.NET would have been about 98% compatible with VB6, VBA in Office could have sat on top of the .NET platform, the platform itself could have been ported to Mac, and we wouldn’t be having this discussion.

To all the people here who are compaining i want to say USE OPENSOURCE !!! Microsoft does as they use python internaly i bet they think it is a better choise but they wil never admit it

A VBA-to-Applescript source translator - or on-the-fly translator/executor

Erik, what’s the situation for third-parties calling into the OLE Automation layer (I believe REALbasic does this) rather than going via the current Apple event interface?

I think that compatibility is way more important than a mac feel. Ridiculously more so… So much so, I, and I think those who know that they are not getting a fully compatible version of office (if you were honest you might label the mac version as “Lite”), will probably be running Windows Office under Parallels.

So another suggestion. Forget the next version. Entirely. I will even deal with a more compatible Rosetta version rather than a Universal version. Just spend all that time on updating the current Mac version. That means file compatibility, fixing bugs, and patching things up as best you can. Rewrite only what needs to be rewritten.

And with that time you should theoretically save from not releasing the next version, begin the painstaking process of porting over VBA scripting and aim for the next major release. I have a feeling I am not in the minority about this at all…

I was stunned by the news, and after reading the long and detailed posts about the hows and why’s, I can only say that the festering sore has finally broken open. It should have been tended to long ago. However, in computer terms, everything seems to be a house of cards and nobody is brave enough to try and fix things when they first realize it’s getting wobbly, they hope it falls to someone else’s watch or the product is replaced or will fade into obsolescense. VBA should have been kept portable and done in a more portable way, but as you say, you can’t go back 15 or so years to suggest this, and you can’t even go back two or three years and start the work anew on making the Mac version work more cleanly.

Having said all that, I do applaud you for the more full support of Apple’s technologies that make the Mac stand out and will integrate better with the Mac workflow, which VBA does not do much for.

So, in that light, please at least consider a way to have Macros in the same sense that are stored in global templates and/or documents that contain the AppleScripts. I have nightmares of trying to keep macros and documents together if they are all external.

Thanks for the open and honest dialogue.

I wrote:

> Office Mac skipped a version in v7 (Office 95) and v10 (Office XP), IIRC.

Ouch; “IIRC” I did not. A few beers on Friday night and all those man-months disappeared. There was indeed Office 2001 (v9) and Office X (v10 for OSX). Sorry for any offence.

CK.

“The OLE Automation layer is still there.”

I did a quick search for an SDK but didn’t turn anything up. Is there one? It’d make more sense for third-party languages to hook in there as it’s much more like the Office/Win API, and cross-platform compatibility is obviously a concern for a lot of folk. Open that up and let the OSS folks have at it. It’d be much easier to do something like VBA->Python translation with vb2Py, for example, if the target API is the same on both languages.

“If RealBASIC uses the OLEAut interfaces (which all still exist) then it can easily drive Office 12, just as it could Office 2004 and X.”

I’m a bit curious that neither Rick or yourself has said anything so far about RB as a potential solution. Porting VBA scripts to RB sounds a much easier prospect than porting them to AS, so it seems an obvious option to yea or nay off the bat. This is not to put down the work you’re doing on Office’s AS support, mind, which is all for the better, but it really sounds like you need to offer existing VBA users some less disruptive transition paths as well. RB costs, but it’s mature and closest to VB so may be an acceptable fit for many VBAers under the circumstances.

p.s. I think you need to put up a bigger sign that says VBA is being killed on ALL platforms and it’s only on 32-bit Windows that it hasn’t stopped twitching yet. Else you’ll still be getting “So when are you supporting VBA?” demands in 2020.

And what about writting a simple C++ VM for the VB opcode?

There is no real need to write a JIT compiler these days.

Did this solution have been study?

For having written such program in the past, it’s not a huge amount of work. It’s also easy to debug and maintain.

Have you think about sub-contracting this part of the development if you did not have the resource internally?

I know this is VB/Office time in the mind of the MacBU, but to tell you the truth, right now, I have an Office that Works quite well (V.x), and does everything I need, so my main desire is for information (anything really) about my favorite app, Messenger!!

I use this app EVERY DAY, ALL THE TIME, and look with horrible envy (insane envy rally) the windows one…

Is there nothing you can tell us, something to have faith, to wait for??

I would really love that

Thanks

I think someone else made a good point that they’d rather run Office 2004 in rosetta than a new version sans VBA. I’d agree with that, except for the new XML based file formats that will need supporting within a year.

I do feel that withdrawing support for a feature as powerful as VBA, which will have had massive customer investment of time, is not something that the Mac BU should countenance. As a developer, I understand the problems involved, and you have my sympathy. But the reality is that for a lot of customers, an Office upgrade with no VBA is horribly broken.

My suggestion? Go back to the drawing board and figure out a way of making it happen.

We have some VBA code on our account dept machines (windows) that gets all buggy when running on our creative dept Macs. It’s only used as a wizard for address and contact info on letters, memo’s faxes and the sort. Since I can’t tell the difference between VBE, VBA or AS I just left it with that. No big loss there. We are currently looking at a completely different way to produce these kinds of documents, so don’t bother on my account. I did come across the suggestion to try and work it in at a later stage or edition of office. What are your ideas on that suggestion, Schwieb?

Now to get back to your question; I want outlook with decent Exchange support on my mac. Not Entourage as it is now.

- Public folders especially public calendars are almost unusable slow
- Loose files in pub folders are invisible
- Planner doesn’t even have info on my own calendar, oh now it does, oh now it doesn’t…
- I would love that fancy, yes/no answer Boolean to work on my Mac
- I want to know when a appoint has a conflict before I accept it
- I want to be able to accept appointment tentatively when there are no conflicts.

The list continues…
I it getting so frustrating that we are now starting to see Exchange server as a hindrance in stead of a need to have solution.

I understand that MacBU took over the exchange client from the exchange group a little while ago, is that correct. May be you can tell us what happened and why you choose entourage over outlook client, which really needed little more that html support and carbonization. (I am probably oversimplifying the problem).

Thank you for reading my rant and maybe even responding.

How about having a chat with REALsoftware and seeing if they’d be interested in mapping VB calls to RB calls? No point re-inventing a wheel that REALsoftware has already made…

This decision alone will undermine all the great new features that are undoubtedly part of Office v.Next, and it will generate a fresh round of bitterness towards the MacBU and Microsoft (er, it already has). As a manager of software engineers, I feel bad for all the engineers who are pouring their sweat and tears into this massive and important update, when all they will hear are rants and tirades about ugly their new baby is, from the very minute it’s born.

It’s also sad to see another reason created for Macs to become unsupported or forbidden in the enterprise. Every time the platform gets closer to enterprise acceptance, something like this comes along and sets it back. It won’t affect me much, personally, but I can understand the angst that other Mac users are feeling over this decision.

Office 2004 is pretty good. Macs will get faster. Rosetta will improve. I predict that Office 2004 will see a longer life than many intended because of this, as its performance on Intel Macs is already “good enough” and it will only get better.

I find that most of the public folder issues i see with Entourage are a problem with that lame IIS/Exchange interaction that likes to go straight to hell every chance it gets.

In the longer term, VBA will be replaced by the Visual Studio Tools for Office anyway and CLR will be used, so how about porting that to the Mac, at least in the next version of the Office after the next version of Office for Mac.

What needs to be expressed to the Mac community is what will replace VB. .Net?

Making Office “more mac-like” and tying it into the core services does make me happy, but we as a community need to know that no matter what platform a file is made on, that it will look and behave exactly the same, and we need to know what efforts are being made in that area.

Just saying “this is going away and here’s why” doesn’t work as well as “this is going away, but this is coming in, so don’t worry, if it’s made on a PC it’ll work on a Mac, and vice-versa”

Last year, I decided to create a program to transcode obsolete ancient Greek fonts into Unicode in all my Word documents (my PhD thesis in particular).

Since such a program could be useful to a lot of colleagues and students, I wanted to make it available not only for Word 2004, but also, if possible, for Word for Windows, even though I do not use Windows myself.

So, even though I would have preferred, being a Mac user, to explore Applescript for Word and use that along with Applescript Studio to create my program, eventually, I ended up creating a Visual Basic solution.

Programming a Visual Basic program on the Mac using Office 2004 is _really_ not fun. The editor is not user-friendly at all (I ended up doing most of my typing in BBEdit and then checking the syntax in VBE). It crashes a lot. The documents that contain the code get corrupted a lot. Etc. But in the end it worked and the program, GreekTranscoder, works under both Word 2004 and Word 2000 (or later).

The decision of the Mac BUT not to support VB in the next version of Office means it _won”t_ work anymore on a Mac. That is to say on _my_ platform of choice.

In other words, selfish as it may sound, since I was creating that program first and foremost for my own use, even though it would prove useful to others as well, had I known at the time VB would be abandonned, I would _never_ have learned it and used it for that project! I would have dug into AS for Word and used that instead. Since such a solution, while Mac only, would still work next year in the next version of Office.

Right now, I’m inclined simply _not_ to upgrade and keep on using Word 2004. I’m an Hellenist, not a programmer, and even though programming can be a fun hobby, I don’t have much time to devote to it.

If I were to upgrade, I would have to rewrite the whole program as an Applescript Studio project.

So, what I’m asking is this: please include a utility to translate — even roughly — the VB code into AS, so that a good portion of the work can be done automatically, even if one then has to check everything closely. Simply getting a good translation to start from will be a big help understanding the AS syntax Word expects etc.

And include tutorial detailing how to recreate a VB form using Xcode and AS Studio. How to link controls to scripts etc.

In a nutshell, offer first-rate documentation. Example, Sample code. And — even rough — translation tools. Comment out the non-translatable portions if you need to. But make it easy to go from VB to AS.

Best.

What do I want from Mac Office?

1) “no matter what platform a file is made on, that it will look and behave exactly the same” as Joe says

2) old bugs fixed: eg the one that means that exporting a Word file containing pdf vector images to pdf produces a file with non-vector images. How old is this bug now?

3) proper support for Unicode in multiple languages. Word 2004 is only halfway there.

I don’t care about VBA, personally, but if it gets in the way of (1), I don’t see why I wouldn’t just run Windows Office and/or NeoOffice instead, unless Mac Office, unlike all previous versions (because of bugs and half-implemented functions), is a real pleasure to use.

I have read all of the comments for the previous article and this one, I know many have said it already, but I will as well.

I have coded in VBA, VB6, and AS for OS9, am now learning how to script for OSX. But this doesn’t mean I have the time and resources to create two versions of everything.

Office on a MAC is good only if documents can be seamlessly used on both platforms at the same time in the same Enterprise or by sending documents to others. A Windows user will add VBA, so this VBA needs to run for the MAC, and be able to be modified there so the Windows user can use it.

If VBA will be going away for Windows, then hook up with the Windows developers and make sure whatever replaces it is a solution for OSX as well. I don’t see a reason to upgrade to a version of Office that is not cross-platform compatible..

chris

There’s a 3rd category of users out there. All Mac companies that trade files with other companies. Architecture and construction are this way. None of the firms (well almost none) live independently. We trade files all the time. It maters to an all Mac architecture firm if VB vanishes even if that firm never ever ever writes a single bit of VB.

As to the two stated objectives of the MacBU for Office. The majority of Mac users I work with (all the way from my 78 year old mother in law to larger firms where I do their IT Systems Administration) only want office to “feel” Mac like. Applescript support is nice but 99% will never use it. Other “core” technologies are nice but what they really want is to be able to open up that Word document their credit union sent them to process for their loan app. Or the “I’ve read this” check off before passing on the critical change order.

Applescript is a total waste for most of these folks. Maybe a useful addition but in general a waste.

I’m all for a 2004 and a half release. Keep my keyboarding and visual styles Maclike. Keeping the PPC version running with Rosetta is much more important than a more Mac like new Office that breaks many of the reasons I work with it. There are other issues but this will keep many many many design firms in the Office 2004 camp with heavy research into alternatives.

Let’s make this very simple:

Office 2007 = Word 6 Fiasco

End of discussion.

I use VBA for Excel, both on Mac and Windows. I use VBA for solutions like this:

1) Delete blank rows from a worksheet
2) Automate the process of filtering
3) Create multiple PivotTables in a worksheet

I like that I can develop a solution on my Mac, and have it work on my PC, or vice versa. I immensely dislike having to redo my work one for each.

But I can appreciate the pain that the Office Mac BU is going through. Considering that so many userforms and controls in the VBE are tied to the OS, VBA for the Mac was always sort of a chewing gum and duct tape solution. (But damn it, I liked that solution…in absence of anything better!)

I might just have to get an Intel Mac and dual boot…get Visual Studio Tools for Office…not the Mac BU’s fault…just the winds of change.

While AppleScript may be a candidate for replacing VBA, it doesn’t appear to offer the same richness for seamless integration or customization of the Microsoft Word: Mac application. Or at least I haven’t figured out how to attach an AS to a button or menu item, capture keystrokes, or create global templates that automatically load AS ‘macros’.

While I can see AS being feasible for occassional use scripts, it doesn’t appear to allow the integration to make AS suitable for production. And without the ability to embed AS ‘macros’ within a document, it will severely complicate third-party solutions built around global templates. In many ways (from our POV), the defining characteristic of Microsoft Office as compared to other text editors on the Mac _is_ that it has cross-platform scripting. Without the macros, Word: Mac is just another word processor.

Our product relies heavily on VB macros (for both Mac and Win versions) for cross-platform compatibility of both file formats and functionality. The loss of VB for Mac has the potential to kill off further Mac development. If nothing else, it’s going to mean a significant redevelopment effort on our part and significant retraining for our customers as the present UI doesn’t appear to be possible via AS. Nothing something I’m really keen on as both tasks, due to their size, have the real potential to distract us from developing compelling new features.

All I can say is that I hope that there will be significant support to the Office: Mac add-on community to assist them with this forced migration. I’m concerned, very concerned… I don’t want to go all ‘woe is me’, but we definitely need details, and soon, of what features/possibilities with VB will NOT be available via AS, workarounds, equivalent and sample code examples, etc.

Having read the details in your posts plus the additional comments listed above I don’t believe there exists a “silver bullet” to this problem. I think the best compromise so far mentioned have been 1) IF VBA is to be depricated in the Office suite of both platforms then work w/ the Windows Office team to delvelop a truely crossplatform solution to automation. 2) Provide for translation tools to help users migrate to the new scripting environment. 3)Some warning to users that documents contain VBA macros that will not execute and must be translated.

Aside from that I have to ask What has the MacBU been doing over the last few years??? Aside from a few hardware drivers, RDC and Office what are you doing? I would have thought that after Office 98 was released a small team of 2 to 4 programers would have begun to build Office using the Cocoa frameworks to eventually move away from the Carbon APIs. The understanding being that it may take two additional releases before a truely Cocoa based Office would be available. I know and understand the deep dependencies on C++ objects from Win Office but please in five years you could have found a very good solution ESPECIALLY in light of Apple allowing the mix of C++ and Objective-C. IF MS planned ahead, with the assumption that they were going to continue to market Office for the Mac, then a long term plan could have been put into place.

If you were to announce that the next Mac Office was 100% Cocoa based BUT had to sacrifice VBA I think that maybe you would not have gotten so much heat, MAYBE. OR five years ago when you made the first release of Office for OS X native had you begun the re-write of VBA then. From your description it sounds like hack built on a foundation that was known to be going away. Too many OS9 and CFM dependencies.

Lastly, related to “What are you doing?” How about porting some other tools like Visio or at least a Visio reader. Yes I know that there are programs that can read the Visio XML format files on the Mac but they are far from perfect. In Office 98 if I received a Word document with a Visio diagram embedded Word could display the diagram and print it perfectly. Today with Office 2004 that isn’t the case. Please spare me the “business case” argument, if there is significant demand in Windows, having a Mac version would have demand if for no other reason then to share files.

Finally how about implementing a full Exchange client for the Mac. Again it has been 5 years since Entorage shipped I would have thought your team, being the largest Mac Development team outside Apple, could have accomplished at least that.

Sorry for the rant but maybe now you can understand why Mac users are very skeptical of Microsoft’s Motivations. If you had workable solution to having a first class native Exchange Client for the Mac would the powers that be allow you to move forward? Or how about the ever elusive Access product? How much power does the MacBU have in setting its own direction and goals and priorities?

Joe Barisa asid “IF VBA is to be depricated in the Office suite of both platforms then work w/ the Windows Office team to delvelop a truely crossplatform solution to automation”

Joe, I very much doubt that the Windows Office group would go for this. The Visual Studio group (responsible for the standalone versions of Visual Basic) would *love* for Office to do this, since they created an entirely new platform and an entirely new and incompatible version of Visual Basic to go with it. (See http://www.classicvb.org for details.)

But as far as I can tell, the Office group took a long hard look at the customer reception and the sales figures and decided they really didn’t want to have a comparable percentage lopped off their sales as well. Three versions of Office have been produced since the .NET platform was released (Office XP, Office 2003 and the beta of Office 2007) and VBA is still there.

I suspect that Microsoft has now done enough market research to convince itself that VBA cannot be dropped from Office unless there is a replacement that will enable VBA projects to undergo a conversion to a new language that is about 98% automatic and therefore relatively painless. 3 releases later there is still no such converter between the old VB6 and the current verson of VB.NET, so I suspect that such a converter is a far from trivial task. I would suspect that a converter to AS is probably harder still. How for instance would an AS program cope with the Application.ActionControl object - the button that caused the macro to run?

From what I can tell, even MacBU would be hanging on to VBA were it not for the recoding involved in the change to the Intel platform. They don’t actually *want* the loss of sales that may result from dropping VBA - even if they are spinning it in order to claim that there will only be a minimal effect.

I accept that MCBU are in a tight spot at present. But their choice really does seem to be between the following options, all fairly unpalatable.

1. Drop VBA for now, take the temporary hit in sales (whatever it might be) and work to put it back next time.

2. Drop VBA permanently and accept the consequences in terms of loss of compatibility and probably loss of sales.

3. Delay the next release until VBA can be included, and accept any loss of upgrade revenue in he meantime.

At present, it isn’t clear whether MacBU will choose between #1 or #2. I guess they haven’t themselves yet made the decision. Their actions are equally consistent (so far) with either path. They seem to have ruled out #3 which would be my preferred solution.

My Ideas!!!
Python sounds sounds exciting, and probabaly a better solution anyways. I’ll have to play a bit with that one. If I understand it right, it’s a write once solution? Now trying to get my windows friends to comply, another subject… It might not be so bad with 2007. That would be a very good how-to/best practices guide so we can write cross-platform scrips.

One of the things we use on the PC side is SmartDocs which from my understanding is tied to .net underpinnings. Namely VB.net. (uhhh… more VB) Mono says that their VB solution isn’t quite ready for prime time yet, but that seems to be the most resonable route. How much time it would require to implement it might be a challenge. I’m shure someone has tried it. Would be a very good post topic!

I have a few other things that would make my life easier. (notes and tasks from exchange, other interface improvements) but those i’m shure you have heard about countless times. That would be for another post:)

Rewriting VBA from scratch will not be impossible or too long.
It is not vital to have VBA pre-compiled: a small interpeter will work great.
The brand new Mac will be fast enough, and having the macro working is very important.

Think twice before destroying the only multi-platform (bi-platform) language Microsoft had.
Please.
bye

I believe this choice makes the upgrade to the next version of MacOffice much less attractive unless the new feature that will be included will make it a killer app anyway; this opens up space for competitors although unfortunately I still don’t see many alternatives out there.

Moreover what worries me is that if we’re still debating about these foundamental issues then delivery of the first UB Office version is probably VERY far in the future although the transition to the Intel plaftorm was announced one year ago.

You seem to understand that this announcement translates into “Don’t buy our product” for those of us who are in the know. But have you t