MacTech’s Mac Office VBA to AppleScript Transition Guide

  • Article

Mac natives inside and outside of MacBU have provided their efforts and expertise to produce a guidebook to help you navigate the transition from VBA to AppleScript. That's right, MacTech magazine's April edition will be a massive 150 page blockbuster entitled "Moving from Microsoft Office VBA to AppleScript: MacTech's Guide to Making the Transition" and is authored by none other than Mac Office MVP and all around great person (so I'm told) Paul Berkowitz. Paul and many of the other Mac Office MVPs work very hard on AppleScript and lots of other important Office topics on behalf of all of us (check out the MVP page to learn more about this group of experts). MacTech - along with Paul and a cast of editors and reviewers whose combined experience with AppleScript and VBA boggle the mind - have stepped up big time with this book.

MacTech subscribers receive this generous tome as their April edition. Not yet a subscriber but want the guide? It's a great time to subscribe and, if you act now (before April 2), you might even be able to get a complimentary subscription. Or, support your local newsstand. MacTech magazine can be found in the mac tech section.

Comments

  • Anonymous
    March 28, 2007
    Does this take into account those people that need have VB Macros function in a heterogeneous environment with other people using Excel for Windows???   If not, then we need to have a transparent system to translate VB Macros for Excel (and possibly Word) for Windows spreadsheets and documents into AppleScript and visa versa.

  • Anonymous
    March 29, 2007
    I agree!  I've come across several programs written in VBA for Excel that would make much of the time consuming parts of my research easier and faster.  Unfortunately, I must either purchase a second Office lisence to run on my VM, or use someone elses machine.  I've actually taken to writting short perl scripts to perform some of the tasks that are easier to automate.  Some sort of REAL cross-platform support for macros would be a huge time saver.

  • Anonymous
    March 29, 2007
    I cannot understand why so many companies out there are able to provide complete cross platform compatibility with thier products, but the worlds largest software company cannot. I remember at MacWorld when Microsoft stood up and introduced Office 98 and apologized for earlier versions (specificailly 6 and 7 that used an identical code base as Windows, but used shims for the Macintosh interface).  Everyone applauded and cheered.  Perhaps they did so not fully understanding what the future would bring. By not using the same core code base, the Macintosh version has seen features removed with each progressive version and Windows features either slowly implemented or never at all.  This should not really be surprising given the amount of work required under this model.

  • Anonymous
    March 29, 2007
    NeoOffice for Mac has announced they'll be supported VB Macros. If an open-source company can do it, why can't MS? I've read the infamous blog post about how long it would take. Fair enough. But how come it hasn't taken NeoOffice that long?

  • Anonymous
    March 30, 2007
    we had a better plan than this transition, we just got rid of the macs and replaced them with windows compatible computers. It makes sense, we got the word that macs weren't really first class citizens on our network anyways, and for complete seemless integration, all of our departments were better served with windows compatible computers. With the staff that weren't able to make the transition to windows because of lack of compatible skills, we made a nice severance package available to them.

  • Anonymous
    March 30, 2007
    Remember. Microsoft business model is to put the company's OS on every PC. Don't forget that. By breaking Microsoft Office for Mac, users that require a heterogenious environment will either have to purchase a PC that runs Microsoft's OS or they will have to purchase the OS to run on their Macs. It's a win win situation for Microsoft in either case.

  • Anonymous
    March 31, 2007
    I need VBA script for my spreadsheet!!!

  • Anonymous
    April 03, 2007
    I've programmed for more than 20 years, across multiple OS's and various hardware platforms. Porting can be tricky, and it may be hard, but it is not impossible.  So, I cannot believe that the decision to eliminate VBA in Mac Office was based on technical issues. I do believe that MS is intentionally making Office in-compatible, or at least limited to Windows OS - as has been done before with other applications (MS Access, MS Project, MS Visio to name 3.

  • Anonymous
    April 04, 2007
    I too am an Excell VBA user and concerned about loss of compatability, however I understood that VBA was being dropped in future versions of Windows Office as well... I await the future with interest.

  • Anonymous
    April 05, 2007
    The comment has been removed

  • Anonymous
    April 07, 2007
    The comment has been removed

  • Anonymous
    April 11, 2007
    The comment has been removed

  • Anonymous
    April 12, 2007
    Gee ... this is all very nice, but I'm still waiting for those Office 2007 translators that were coming "free and fast" back on Dec. 5, 2006. I guess if I had to sit and watch Windows boot every day, I might think five months was "fast", but ...

  • Anonymous
    April 12, 2007
    Yes I understand what a framework is and that there would be pain involved, however, as you state there is a "lot of legacy code" some of which may be unecessary or inefficient on today's systems. Sometimes you need to refactor how you do things to make them more efficient and/or take advantage of more features. I suspect moving beyond Lepord Apple will continue to aggressively evolve the Cocoa frameworks and Carbon hooks will continue to be updated to a point but it appears to me that Cocoa is the future and Carbon is the status quo. Most recently it has been rumored that Apple is gutting portions of Quicktime (as I understand the blue print to getting Carbon into OS X to begin with) to make them more accessible and feature rich to Cocoa frameworks. I also suspect that the new "Core" managers will be very easy to implement and make use of in a Cocoa based application then Carbon. What IF Apple were to change architectures again, say Cell or Itanium  or Sparc (all of which are highly unlikely but worth an IF) I suspect that Cocoa authors would have a much easier time migrating to that New architecture via Apple's intrinisic tools and the Cocoa framework then Carbon framework based applications.

  • Anonymous
    April 13, 2007
    The comment has been removed

  • Anonymous
    April 16, 2007
    My comments have nothing to do with the compentency of the MacBU, rather more to do with the business practices of Microsoft. IF Mac Office was in their long term strategy (assuming 2 or 3 releases from Office X) then shouldn't they have had teams evaluate and look to migration over time to the new frameworks and runtime environment? (Very much like Apple had been doing with OS X on intel OR Intel was doing with the Core platform?) I am sorry the whole VBA engine is something that should have been addressed a while ago, especially if there was a long term strategy for Mac Office. If you read these posts you will see there are quite a large number of people who will not be upgrading to this new version because they view VBA compatibility between the Windows and Mac world to be the keystone in the product. People have also been clamoring for Access and a full Exchange experience, yet MS seems to ignore these requests (yet they have no problem loosing money on Xbox, Zune, MSN, MSNBC etc).  

  • Anonymous
    April 17, 2007
    <I>IF Mac Office was in their long term strategy (assuming 2 or 3 releases from Office X) then shouldn't they have had teams evaluate and look to migration over time to the new frameworks and runtime environment? </I> Maybe because Steve TOLD them "Carbon is for existing Mac apps; Cocoa is for new Mac apps", and they found that to be true when they looked at it? Keep in mind that it's not just Microsoft that releases their apps in Carbon: Adobe also does their Creative Suite in Carbon, too. So is Adobe part of this conspiracy, too? <I>If you read these posts you will see there are quite a large number of people who will not be upgrading to this new version because they view VBA compatibility between the Windows and Mac world to be the keystone in the product.</I> It's unfortunate that almost 20 years ago, the folks responsible for VB implementation on the Mac didn't realize the MacOS would be ported from 68K to PowerPC to Intel, and that Metrowerks would go out of the compiler business, so they implemented VB on the Mac in a way that makes it very, VERY hard to do a straightforward port that doesn't involve years of additiional work. That's a design flaw under the circumstances. That being said, being able to see 15 years into the future with your code is quite the engineering feat. Apple didn't even do a good job of it back then (think Pink/Copland).

  • Anonymous
    April 18, 2007
    In my experience I have not had issues with Adobe files being created on one platform not work on the other. Nor have I read of any glaring feature ommissions between the version for Mac vs Windows for their cross platform applications. I do not use there software extensively so I cannot say with 100% accuracy this is the case. As you point out though the Applications in Mac Office have been around for about 20 years now. The versions of Excel and Word where originally written in a USCD Pascal type compiler that I believe was running on a VAX compiled down to PCODE with a PCODE interperter. Then in 1994 time frame when the Mac version of the Office package was released as a product those versions were written using MFC, an attempt to cross compile the native Windows version to the Mac directly. That unforutnately for many people was the worst versions of the applications. Thus the re-write for Office 98 with the foundation of the MacBU and the transition to Mac native tools like Codewarrior and about the same time when the VBA solution that is in use today was created.  So there is at least three times when major foundational, possibly major re-writes of the code base has occurred. Specifically relating to VBA my understanding/reading of how they implemented it in Office 98, while "clever" and  "insteresting" appears to have been a bit of a nightmare to maintain even if OS 9 and Codewarrior were still around (things like 64-bit, enhanced insturction/ABIs, too many compiler/assembly dependencies etc. (observations from schwieb's blog) At some point with the migration to OS X and 64 bit computing, forget the intel migration for now, this was going to need a major overhaul. Better sooner rather than later.

  • Anonymous
    April 21, 2007
    Please excuse me for using critical words - this guidebook is totally nonsense. The reason people use MS Office on Mac is just because they need to read/write files made on Windows. If applescript on Mac version of Excel does not work on Windows, there is no reason for people to use Applescript on Mac. Totally nonsense and outrageous movement.

  • Anonymous
    April 30, 2007
    I write VBA macros in Excel to run on both Macs and PCs. Please tell me how changing from VBA to AppleScript will allow me to continue to support PCs. Will the next version of MS Office for PC support AppleScript? If not, this guide is less than useless, I'll have to ask my clients to switch to OpenOffice instead.

  • Anonymous
    May 02, 2007
    The comment has been removed