Schwieb, this is not a technical decision, regardless of your pain. It’s a political one. If you guys delude yourselves that people buy Office:Mac because it’s “Maclike”, or has great features, or is “better” than the Windows version, think again. They buy it because they have to in order to survive in an Office/Windows dominated world. They sure as hell aren’t going to buy it for Applescript.

At a time when large (>10,000 user organisations) corporate and government customers are beginning to return to demanding cross platform compatibility for software (at least in our category), you are dumping this very capability from your own product.

This is not about “telling you what we want to do”. Mapping feature for feature to Applescript, RealBasic or any other technology is like blowing in the wind.

100% document fidelity must be your foundation, then and only then can you erect your stated dual pillars of “Maclike” and “Winlike” on top of it. Document fidelity is a composite of presentation AND behaviour. That means VB in your world.

Please note that this isn’t an endorsement of the nightmare that is VB/VBA. However you guys made this bed. You have to lie in it. Weeping for the MacBU or the fact that none of you wrote this code is hardly a mature position to take.

The only way it is acceptable to dump VB is if the announcement is couched in terms of “Microsoft is end-of-lifeing VB on all platforms as of 2008, replacing it with xxxxxx.” Try doing that to the Windows world. Not going to happen.

Please reconsider this untenable proposition and restore confidence to what, until now, was a fantastic renaissance starting with Office:X

However, yesterday I was reading about Silverlight and a mini-CLR from .NET running on Mac OS X.

Which leads me to the thought that perhaps if next Windows Office uses VisualBasic.NET rather than VBA — which seems like a sensible idea to me — it could be possible for the next next version of Office on the Mac to also use .NET?

I am just reading the April 2007 MacTech issue on moving to Applescript from VBA. I seems like it deals mostly with formatting worksheets. Nothing about hard core number crunching user defined functions.

This is really incredible corporate integrity.

Cheers.

It is my experience that the majority of Mac users / Mac businesses purchase Office because it is a good program and cross-platform compatible.

I strongly urge the MacBU to put more resources on cross-platform compatibility, and less resources on Mac specific features. Office is a good program on Windows - just give us the same. In fact, it is difficult to work with others (on Windows) that do not see the same menu options, features, etc.

Thanks for Listening

It would insure compatibility with newer files and ‘buy time’ for the VB rewrite which could be done in a ‘more modern method’ to allow for future architecture changes…

What about using spawned processes to handle the macro steps? Spawn to GCC or other available language. I’ OS and Kernel ignorant but threw it out anyway.

What about creating a ‘pro-version’ of Office for the Mac that would roll VB or a follow-on bit to add the functionality. MS wants to make more money, right? There is another way to get ‘mo’ money’…

What about the idea of killing the PPC code for macros? Hell, I’ve bought software that wouldn’t do certain things because of the hardware that I happen to have so why would this be that much different…

What about turning the proposal for a new Mac/Intel VB over to the Idia programming group and letting them prove why they are better than using American programmers… I mean, if they are that ‘cheap’ that everyone is flogging themselves to jump there, why not use them… Heck, you must be able to use 10 for the cost of one of the formerly employeed American programmers wandering the streets… OR, better yet, why not submit the code that you have, all of it, and allow outside groups to do the dirty work for you. I know that looks like ‘open source’ but it might work… It would help keep out of work programmers busy and keep them from writing violent porno laced video games…

Sorry for the snark… I was replaced in a prior career by a ‘team’ of programmers in India…

PS: Is there a version of Basic for the Mac? I didn’t realize there might be which leads me to another possibility: What about switching macro’s in Excell to another language than ‘VB’ on the mac and depricating ‘VB’ on the PC too… I’m sure that a ‘better’ language could benefit BOTH the mac and pc realm…

1. I don’t like Office. I think it’s ugly, confusing, slow, irritating, buggy, and generally rotten beyond description. I think Office isn’t even worth the HD space it takes up, never mind the considerable amount of money it we have to pay for it.

2. Despite my strong personal dislike, I always buy Office and install it on all of my computers. There is one single reason for this: Other people insist on producing .doc and .xls files (forgive them Father, for they know not what they’re doing), and I need to be able to open them. I’d certainly never tie any of my own work to these untrustworthy and proprietary formats, and keep praying with fervor the rest of humanity will come to it’s collective sense, but until that cold day in Hell comes to pass, I do need Office.

3. If a future release of Office looks any more or less like it belongs on a Mac is completely beside the point. It could look like it belongs on a Commodore 64 for all I care, I don’t like it anyway, and avoid using it whenever possible. The day I don’t have to start up Office at all is a happy day indeed!

4. The question whether feature X should be added or feature Y dropped from Office falls completely outside of anything I’d ever care about. I’ll be certain to use feature X precisely as much as I have previously been using feature Y, that is not at all, ever. Feel free to add as many paperclips and puppies and wizards as you like, it matters not the least to me. The ONLY feature of Office that has any value whatsoever to me, is the feature of being able to open all the .doc’s and .xls’s produced by those unwitting people out there (bless their ignorant little hearts). Amazingly perhaps, I’ll pay a stiff price for that feature alone.

5. A new Office version that cannot open .doc’s and .xls’s reliably is as useful as a – sorry, my imagination isn’t vivid enough to imagine anything equally useless to compare it with. Most useless things in this world can at least be used as doorstoppers, but the bits and bytes that make up Office aren’t even good for that, lacking the neccessary substance. No new feature of Office can possibly make up for such an inability to open the files it’s meant to open. Take away the sole reason for a thing to exist, and what do you get? Nothing.

6. I will not install any such crippled version of Office on any machine I own, not now, not in the future. I will rather install any other combination of software that performs the necessary function, even if this should end up being a whole Windows partition with a proper version of Office to go with it. I don’t like or want Windows on my HD any more than I want Office, but we’re talking about pure necessity here. If Microsoft intends to scrap Office for Mac, and thereby force me to buy two products instead of one, it’s a sacrifice I’ll just have to make. If Microsoft decides to bleed me, I’ll bleed, simple as that. That is, unless someone else offers another solution to the sole problem uniquely solved by Office: The problem of reliably opening .doc and .xls files produced by Office on Windows. In that case I give Microsoft the finger.

Am I alone feeling this way about Office? I think not. I understand it can’t be very fun to work on something so unloved, but the fact is, very few people buy Office because they love it, especially Office for the Mac. If you imagine otherwise you’re lying to yourself.

What should you do then?

You should make Office 100% cross-platform, at the very least as far as document compatibilty goes. For your own good, it should really be compiled for the different platforms from a common source tree. To have two teams working on two versions in parallell is just incredibly stupid. There’s no other way of putting it. Such an organisation wastes money for Microsoft, while at the same time guaranteeing compatibility problems for the end users. And as I said, no amount of ‘other benefits’ can possibly outweigh this! Of the two Office versions, the Windows version is obviously the reference version. The Mac version needs to be exactly the same, not better, and certainly not worse.

1. How about a feedback option where users can submit bugs, suggestions and feature requests similar to Apple’s iLife products.

2.A plug-ins set of programming templates that would be installed if xcode is present. Those who would like to write plug-ins would have the tools, interfaces and libraries present when they launch xcode.

3. Excel specific- How about a collection of BitWise functions like
value1 is an integer value of byte size “size” (1,2,4,8,16,32,64,128,512,1024)
value2 is an integer value of byte size “size” (1,2,4,8,16,32,64,128,512,1024)

Returns an integer value of same size.

BitAND(value1, value2, size)
BitOR(value1, value2, size)
BitNOT(value1, value2, size)
BitXOR(value1, value2, size)
BitNAND(value1, value2, size)

Bit test would be slightly different with value2 = to the 0 based index of the bit you wish to test (assuming a BigEndian formatted number)

BitTEST(value1, value2, size)

4. Excel based function. GetItem(string, item, del)

Returns a sub string containing the item “item” of the string that is delimited by “del”.

For example a string formated “fe80:0000:0000:0000:0216:cbff:fec0:c479″
GetItem(”fe80:0000:0000:0000:0216:cbff:fec0:c479″,3,”:”) would return “0000″ as its value.

5. Excel based function SetItem(string1,string2,item,del) would replace item “item” in string1 with the contents of string2 using del as thhe delimiter.

That way, you don’t have to port anything, and people still get access to the new features of Office. Then, when you’re ready to release the x.5 release and have figured out how to get VBA to be fully native, the first time Office notices itself being launched on an Intel Mac via Rosetta it can pop up a dialog box saying “Thanks for your patience! You can uncheck that box now!”

The same lame excuse was used by the IE developement group when asked why does IE _still_ not support XHTML in a standards-based way. What it boiled down to was a choice between doing it correct after several years of doing nothing and slipping the release schedule or leave it broken with promises to fix it now that they can catch their breath.

Cross-platform compatibility or nothing is how I feel. Stop wasting time making excuses and get to work _now_ on doing it right!

Our department has one Mac lab and one PC lab. We teach both platforms in order to provide students with the ability to work in both environments. As such, we have to have cross-platform functionality.

I have written dozens of Excel VB programs for our students and our college. They are used on Macs and PCs alike. I’m sure a programmer would wonder what I am thinking if I shared my code, but the point is, that I can do it, and the programs work.

Literally, I have spent thousands of hours over the past 15 years writing vb in Excel. For example, my graduation planning program has been in service since 1991 and still works fine. Nearly 2000 students have used it, on both Macs and PCs. Another program was written for managing an urban forestry database. It is 13 MBs of code. Why in Excel? Because that’s what the majority of the everyday users know, and they can use it with minimal instruction and with familiarity.

Excel is a fantastic program and I have taken every opportunity to expose our students to its capabilities.

Now what?

Run a whole computer lab with Parallels?
Stay with Excel 2004 until I die?
Only hire new faculty that use PCs or don’t use VB?
Dumb down the curriculum using non-VB spreadsheets?

I’ve never seen such a disservice to MS users in my life. Rather than share my feelings, I’d rather ENCOURAGE RECONSIDERATION. We have been faithful MS proponents since Excel 1.5. Don’t leave us without feasible or realistic alternatives.

What do I want? I want VB in Excel — even if I have to wait for the next release.

I don’t know whether there is an easy way you could achieve this.

Oh and I find the “Record, Macro” function quite handy. Please make sure this can still be done with AppleScript. (Actually can you give us this as an update to Office 2004? It would give us a chance to prepare for the change.)

My suggestion to your problem :
- publish the current Mac VBA / VBE etc. code to open source
- contribute one FTE (full-time equivalent) to answer questions from the open-source community
- open handles between Mac Office and VBA, and implement a scripting engine plugin architecture between Mac Office and Automator/AppleScript.

This way, you could expect the open source community to design, develop, test and deliver an open-source VBA engine to plug into that architecture, maybe even in time for the Office 2007 product release.

If you could finance some of that development (or tesing), that would be even greater … !

It seems pretty clear from reading these posts that cross-platform compatibility is higher on Mac customers’ priority list than you thought. Given the substantial impact the loss of VBA has on cross-platform compatibility, I wonder if you could respond to these suggestions, and give us an idea whether tweaking RealBasic or open-sourcing VBA are under consideration as possible solutions or, if not, what the barriers are.

Also nice would be some indication whether the “next generation” scripting language will be cross-platform, and Mac compatible.

Thanks
Carroll Wills

P.S. FWIW Though I am not a “power user”, I also believe that cross-platform compatibility is, and should be the highest priority. MacOffice is a great product, but its single most important feature is the universal file formats, which allow us to work in a Windows world. I daresay that, for the vast majority of us, Office 2004 will continue to be useful for sometime ahead, but only if it can play well with Windows … in whatever form it takes.

My .02

I wandered through CompUSA today checking out the new Mac Books and I tried Excel 2004. Under the Macros area it offers a choice of either the VBA Editor or the Real Basic Editor - built in!

Does anybody know about the built-in Real Basic editor or will it also go unsupported in 2007?

My bigger question is what happens to our user-defined functions and formulae in the new version of Excel?

On the Mac it is not really worth the money because it turns out to be a substandard product when compared side by side to it’s Windows counterpart. Office 2004 doesn’t even come close. Even the wizards are a goofy substandard version.

For example, viewing page layout after completing the envelope wizard, the text is there. Looks great and ready to print. Click over to Normal View or Preview and the text is gone… and that’s what it prints… a blank page. I’m no expert, but if this were Windows, it would have been fixed already and two hours later, I wouldn’t be typing this on Schwieb’s blog.

Why can’t Microsoft just make one source for Office and port it to Windows, OSX or other platforms? How hard could this possibly be?

Thanks.

The converters are going to be released for ‘04 in a few months - that’s already announced. For folks asking MS to use a cross-platform scripting language, they really have no impetous at this point, given the large install base of folks that know VB already.

Instead, if they took the Monad approach, where it was a generic scripting engine with language plug-ins, then VB is just one of the options, AS could be another, Perl, etc.

Just my suggestion.

Also, I agree with the majority of the people on this blog: Make the next scripting language cross-platform from the get-go. If you (and WinOffice) do, you will hear the collective sigh of non-frustration as MacOffice users will use this language gracefully with their Windows neighbors.

That being said, I would like to see a “Rosetta-like” translation of code. VBA instructions written on Win Office get a checkbox to “Compile for Mac”, AppleScript instructions on Mac Office get a checkbox to “Compile for Win”. Each office product would then be able to translate the instructions into it’s native format. It’s a sort of .NET approach where it doesn’t matter what language it’s written in. Would it be possible to have the Mac / Win Office BU’s get together on this?

Honestly, if Office for Mac isn’t compatible with anything but itself, I can’t think of any reason for anyone to buy it (except if they are ignorantly assuming it can read Windows Office documents). Claiming compatibility without vb support is basically a marketing invention and not compatibility in any real sense (WAAAYYYY too many spreadsheets have macros for any organization that uses Excel to find this acceptable).

I can’t argue whether it is worth Microsoft’s resources to port VB6 to Office for Mac, but if it’s not, then just kill the product. There’s no reason to release a product if people will only buy it by mistake (i.e., thinking it will read Windows Office documents). There are plenty of free and cheap alternatives that read Office documents without macros, and none of them are used by businesses either.

Without VBA support, we will not be upgrading. In fact, I may need to pro-actively purchase Office 2004 licenses so I am not forced to use broken Office release. Because without VBA support, Office is broken.

I agree this isn’t perfect and still has them reworking old code - but I’m afraid there isn’t really a good alternative. Droping support entirely is the least best option as it drives office (eventually) out of the corporate world. Not right away, but it will curtain sales of office (as pointed out ad naseum here). I know the smart folks at the MacBU realize this, so obviously they’re taking a calculated risk. How much risk? Probably not much in the near-term, at least once the WinOffice ‘07 converters are available. Few corporations are going to immediately buy and deploy new versions of Office on either platform - they’ll start their integration testing, etc. Most corporations will keep the current Office ‘04 + converters in place for now and it will work just fine. Long-term, though, the landscape changes considerably.

Over time corporate IT departments will turn their plans to phasing out Office on the Mac and looking to alternatives, such as Parallels + WinOffice, especially given Parallel’s new abilities to run Windows apps in a seamless window off a bootcamp drive. This will satisfy them, since it becomes a single support solution, while still allowing those ‘Mac heads’ to keep their current systems.

The morale of this story is that the MacBU could still turn it’s attention to porting VB, warts and all, over a greater timeframe than the main application. If they took that course and announced it will be delivered later this year (or heck, even early next year), it would change everything.

1. Corporate users would be fine keeping what they have today (plus ‘07 converters) AND be able to justify Mac purchases going forward.

2. IT depts. would be assured that the new functionality was coming and could plan their testing/roll-out, etc. To them there would be no break in functionality.

3. Small-business/home/etc. users will purchase MacOffice ‘07 when it ships (those that don’t need VB support). So they get a new release AND they get to debug it before corporate users get it later on. This is a good thing as there will be several bugs fixed before the VB-edition would be available.

So, while the cost and complexity is there, the pros outweigh the cons from a customer standpoint. We understand it isn’t easy (working with old, crufty code never is); however, it is truly necessary for the long-term longevity of MacBU. Not today, or probably next year, but starting in ‘08 without VBA, MacOffice sales into the corporation will start to falter.

And no one wants to see that!