Macros an obstacle to office suite compatibility

Given the extent to which corporations use macros, this is a rather remarkable gaffe. Putting off implementation is one thing, putting off approach is something else.

Macros are not some hidden "could happen one day" kind of thing. They are a significant part of everyday life for many heavy users. At the very least, a "macros will be here and work this way" box needed/needs to be in place to avoid investing heavy time/money in something that may or may not work well with them.

Presumably all will be fixed in the end, but this definitely sounds like a case of inexplicable short-sightedness.

It looks like someone is implementing VBA for OpenOffice.org:

http://www.gnomebangalore.org/?q=blog/267

I can see that, using VBA would be beneficial for migration; But I would rather see Python, Perl, PHP and even JavaScript used for the long run. We have been spending to too much time and effort to interoperate with Windows; I hope one day we wont have to be too concerned about that. Let the burden fall on MS instead.

The specific macro choice seems less important than having a well-defined way to implement macros right from the start.

A clever implementation might even be language-neutral. It's just that people who rely on macros really do rely on macros, and it doesn't seem like the sort of thing that should be handled as an afterthought.

Users who rely on macros usually have a sizable catalogue of them built up and refined over time, so it's no small thing to start over. But I don't see where learning a new macro language is going to be a hindrance at the corporate level, because programmers get assigned to writing them, not ordinary users. Very few regular users ever learn to write their own macros, so it's not like legions of MS Office users are going to wail about having to learn a new macro language.

What will happen is what always happens with migrations to new platforms and applications- the old stuff will hang around for a long, long time, it won't be replaced.

**die die VBA stab**

There, I feel better now.

Dino: I thought Open Office has a pretty good API, are you saying that Macros was not in their original design? I find that hard to believe! I think it was a matter of priorities not an afterthought.

I am not sure what you mean by "language-neutral", are you talking about bytecode implementation or support for all scripts? could you elaborate?

Abe:

I'm not talking about Open Office, which has very good macro support.

The problem is that macros can be included in documents, and the OpenDocument format, if the author is correct, doesn't make any allowance for that. To me, that's a major goof, especially since it doesn't require an actual implementation in the first pass, just sufficient acknowledgment and conceptualization to assure interested parties that macro implementation within OpenDocuments will not be a problem

Dino:

The beauty of XML is its flexibility and eXtensibility. It is dumb but very structured data. It will even allow garbage and it wont even bother it because what counts is the schema and the interpreter. If a tag doesn't make sense, the interpreter ignores it. That is what makes it backward and forward compatible (although you lose the new tags if you go back).

So, adding scripts makes no difference as long as the interpreter has the handler of the script(s). So you can make language-neutral as long as the script interpreter is present and enabled.

I personally never liked Macros although they server a purpose. I also think, because of the integration of data sources, Macros will be much less important.

Another one of the MS secure features... Anyone having the macros turned on in word and then handling external docs is just asking for it. macros are far better off being handled as routines only in the app interface.

jimf -

That's problematic with documents in which little time-saving macros may perform a lot of the drudge work in creating the final appearance. If the receiver doesn't have the macros, the document doesn't render properly.

Now...Should there be significant limits to the things a document-borne macro can do?

Oh yeah.