Clarification on VBA Support

Why not make it optional? It would also be possible to promote third party implementations if Microsoft would standardize it, and thus publish the specification. That could be a real benefit for Mac users.

Anyone know how to stop this:

It’s not the F8 key…there’s an unusual problem where the mouse selects more cells than I’m asking, it grabs random groups of three of more….even when F8 is off.

I'm a user, not engineer, and I know one other person having the same problem.  What the heck is it?  I've used Excel for years.

Thanks!

Dawn

Thanks! This clarification comes from Microsoft itself is very important to Excel developers, although it is impossible to imagine Excel without macro language and also to imagine another macro language better than the VBA and XLM together.

Can we please please have the developers road map for Excel developers?  What technologies should we use - in the view of Microsoft.

I've been asking for more than a year - come on, it's not a lot to ask for....

so you're only screwing MAC users with existing code. nice cross platform support, microsoft. support two completely separate script technologies in excel. PC users can use one of the blessed microsoft methods, or older legacy VBA. mac users can write applescript.

can you NOT imagine a scenario where there are MACS and PCS accessing the same spreadsheet? REALLY? You can't? Seriously. NOBODY thought that would EVER HAPPEN?

>> so you're only screwing MAC users with existing code. nice cross platform support,

Do you really think that Microsoft is going to do anything that makes it easier customers to move from Windows to OS-X?  Even without these landmines, OS-X marketshare is rising quickly.  Microsoft is now in circle the wagons mode.

Why not? Office is the product. Not the Operating System.

We've solved the problem with lack of vba support on macs, and it was very easy: we got rid of the macs. Typically our mac users were pretty expensive to support, being on average less skilled and lacking in knowledge of basics like what a file is, how to search the web, etc, and additionally were routinely late to work and were relative to the rest of our staff unprofessional in demeanor. So in addition to getting rid of the macs, we got rid of the mac users.

Trust me, this methodology can clean up lots of your companies processes and deadwood employees. Give it a try!

I agree with your comment Scott.  Microsoft needs to incorporate cross compatibility with their products.  Especially if their offering the package to corporate users.

Ha.   You're a cute troll, officefan.

Office 2004 for Mac DOES support VBA.   So all Microsoft did was waste a lot of development time and money on Office 2008, because any customers who need to use spreadsheets with VBA in mixed environments will NEVER UPGRADE from Office 2004.

Dawn, try hitting the esacpe key.

www.schwieb.com/.../saying-goodbye-to-visual-basic

explains why VBA was dropped from Office 2008. I can't say I agree with the decision, but it

is clear that there is solid reasoning

behind it.

What "solid reasoning"? One of the biggest software companies in the world doesn't have the resources to port Mac VBA from PowerPC to Intel? That's nuts! Windows VBA is on Intel, so they should be pretty much there, right? This is totally a marketing move to drive people to Windows. I can't see any chance at all that this has to do with developer resources.

Paul, you need to consider that Mac Office sales are nowhere close to Windows Office sales. The way Mac Office can keep up is borrow broadly from Windows Office development. A port of VBA to Intel Mac OS is not something they can borrow, hence the lack of resources.

And they added some exclusive eye candy for Mac users, credit them that.

Paul, if you read the article that mjb linked to *thoroughly*, you will see that it really isn't a simple case of picking up the Windows VBA code and using that. The Windows code is in a slightly different assembler dialect than that understood by the assembler for Intel Mac, for starters. That's not too hard, but the Application Binary Interface is different. That means that the set of registers that are reserved for a routine, and when they have to be saved and restored, are different between the two platforms, and the way parameters are passed is different, and exception handling (which may be important) is most assuredly different.

Keeping the VBA feature would also mean keeping the existing PowerPC support running, as Mac Office 2008 is supported on both PowerPC and Intel Macs. I think Office 2008 moved entirely to Mach rather than CFM format even on PPC, to help with porting, so the old PPC code would need to be modified for the new format. Then the PowerPC and new Intel code would have to be made bug-compatible (which I would not expect independently developed implementations to be, in general) so that a user's macros don't break when they move from a PowerMac to an Intel Mac. We'll leave aside the issue that the PowerPC version is a JIT-compiler while the Windows version is an interpreter!

Just because you have lots of money doesn't mean you can actually spend it. At the same time, Rick Schaut (at blogs.msdn.com/.../693499.aspx) mentioned they had funding in the budget to bring in more developers but were unable to find suitable candidates. Hard to assign work to non-existent employees.