![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Greetings,
When I wrote this, almost 10 years ago, things didn't looking too good
for "inter-suite" macro compatibility:
http://archive09.linux.com/feature/47935
today, I have the feeling thing's haven't really improved, when it
comes to macros inserted in ODF files, even considering only the
FOSS-based suites, i.e. AOO, LO, Calligra... but I am not sure. What's
your opinion, or reports from the trenches? Any feedback is welcome.
Thanks,
Marco
Hi 
I have a feeling that macros were OK between LO and AOO a couple of years
ago but there have been huge developments in LO during that time so
compatibility has probably suffered a bit.
What happens to a macro written for LO that calls functionality which
doesn't exist in other suites? Also what happens if the functionality does
exist in another suite but is handled differently?
If written for AOO then i suspect it'll probably work in LO. Or if written
for LO and manages to avoid the newer features then presumably it'll work
in AOO too (but cross your fingers jic!). Obviously this is also going to
be a problem with macros that people try to run in older versions of
LibreOffice. So if compatibility is a main concern then avoid using newer
functionality!
All this is also a problem in MS Office, of course. However they have the
additional problem that even sticking to basic functionality is often a
problem between different versions and that happens even if the version of
MSO is newer than the one the macro was written for. At my workplace we
are stuck on MS Office 2010 and can't upgrade or move to 365 due to this
issue. Rewriting the macros each time we need to upgrade is a pain.
At least with the LO macros the languages used are the same in each
upgrade/update and the same as those used in other office suites. So
re-writing is less of an issue. It would be better for us to re-write to
LO macro-code because then we would only have to do the re-write just the 1
time.
However all this is only my own opinion and could easily be wrong. I do my
best to avoid macros.
Regards from
Tom
Do the other programs you mention support macros?
When you write a program, you have a set of routines, functions, and syntax that is supported (roughly speaking although not totally accurate). This part of the language means things such as "how do I wrote a loop". Then you have the part of "how do I control a specific word processor". The part that you use to control the word processor is very specific to LO internals. The language itself does not provide a means to manipulate what might be contained in the document. It merely provides the framework that you then use to control the program. I can control MS Office from a macro in LO, and that has nothing to do with specific commands in LO that you can use to manipulate a document. It is how you use the language to use the "stuff" provide by MS to control office. The "stuff" that you use to control LO is very dependent on the internal implementation of LO. So, those specific objects and such will not exist in another application.
Based on this, I suspect no compatibility. A macro in LO is mostly compatible with AOO. They are diverging, so things will only get worse.
M. Fioretti wrote
When I wrote this, almost 10 years ago, things didn't looking too good
for "inter-suite" macro compatibility:http://archive09.linux.com/feature/47935
today, I have the feeling thing's haven't really improved, when it
comes to macros inserted in ODF files, even considering only the
FOSS-based suites, i.e. AOO, LO, Calligra... but I am not sure. What's
your opinion, or reports from the trenches? Any feedback is welcome.
Michael Meeks (LO developer) has commented about this issue, in relation to
the recent UK Government ODF adoption proposal, in his blog post from
2014-02-26 (under the heading "Macros expose implementation details"):
https://people.gnome.org/~michael/blog/2014-02-26-cabinet-office.html
I have also written about this issue in a forum thread here:
http://en.libreofficeforum.org/node/7985
In short, a specification (ODF) will never define implementation-level
detail (API) and nor should it be expected to do so. Use of macros (API) is
effectively a form of implementation (i.e., vendor) lock-on that has little
to do with a file format specification. If an organisation is dependent on
API-level compatibility, they are dependent on a software product rather
than a specification. The situation with ODF or any other file format
specification will be unlikely to change this. This is a story that repeats
itself in many forms of software and not just office suites and is also the
reason why some large organisations prohibit the use of API-level
development (as it reduces the ability for adaptation).
Best wishes, Owen.
Andrew,
no offense meant, but at first sight this reply of yours sounded to me
as just an expansion, much better worded of course, of what I myself
wrote in that piece in 2005 I had linked to initially:
http://archive09.linux.com/feature/47935
then I thought: maybe you mean that the second category of macros I
mention there (those for "one specific document") doesn't really
exist, or cannot really exist?
Thanks,
Marco
Hi
I feel that going with Extensions is better than doing macros. It seems to
affect LO in a more general way rather than 1 document at a time. It gives
an opportunity to submit the code to the main branch for possible adoption
for everyone. It sounds like it might be easier to modify the code to fit
into other office suites or programs.
Macros seem kinda the MS way of thinking and doing things. It seems
designed to lock people in and limits sharing by creating things that are a
bit proprietary and somewhat brittle.
On the other hand have a quick way of just recording actions and then being
able to replay those actions easily seems like quite a good thing to do but
there are inherent flaws in that sort of idea anyway. It would really need
someone to go through the coding to make sure there are no obvious blunders
or ill-considered actions that are likely to cause harm in a different
context.
Most of the experts with macros seem to say the best way of using them is
with as light a touch as possible and use them as minimally as possible.
There are bound to be times when things can only be done by using a macro
or when it's temporarily a good idea but that doesn't mean it's always the
best way!
If people really just want to do everything the MS way but have a kinda
cheap MS clone then they are really missing out on a lot of the wealth of
opportunity that OpenSource offers.
Regards from
Tom
yes (and I agree with everything else you said) but... going with
extensions is something that only what, 0.00001% of office suite users
know how to do?
for most people, the choice between:
- learning to write real extensions (assuning they do HAVE the skills)
- waiting that somebody writes them
- writing themselves a quick and dirty macro that does almost
everything they need
is a total no brainer, isn't it? That's why I ask about "macro
interoperability". The less macros there are the better, sure, but
let's have a clear idea of what is possible, or should be avoided.
Hi Tom
TomD wrote
I feel that going with Extensions is better than doing macros.
They have different goals. Extensions are for automated solutions that could
be interesting for other users.
Macros are for quickly solving your own itch.
TomD wrote
Macros seem kinda the MS way of thinking and doing things. It seems
designed to lock people in and limits sharing by creating things that are
a
bit proprietary and somewhat brittle.
The fact that the VBA is for Windows (and Mac?) is not related to locking
people in. VBA is a scripting language shared by all MSO programs to allow
automation. The fact that Windows is the dominant OS (and MSO the dominant
office suite) is what contributes to the spread of VBA...
VBA scripts are available from many sites and is what I use for solving
similar problems (since I don't know how to code). It's not so easy to find
BASIC scripts...
TomD wrote
There are bound to be times when things can only be done by using a macro
or when it's temporarily a good idea but that doesn't mean it's always the
best way!
IMO sometimes it's the only way, unless you want to manually repeat hundreds
(thousands) of time the same action taking you much more time (and
increasing the probability of human errors)
TomD wrote
If people really just want to do everything the MS way but have a kinda
cheap MS clone then they are really missing out on a lot of the wealth of
opportunity that OpenSource offers.
I think you are being an Open Source fundamentalist. Creating and using
macros doesn't drag you to the dark side of the force...
Macro users who can't code (such as myself) would be happy if there was a
tool to convert VBA macros to BASIC. Then we could switch to LO/AOO...
Just my 2 cents
Pedro
Agreed. Any complex software with which I'm going to spend a significant
amount of time has to have strong and well integrated automation
features (call it macros or whatever you will). Otherwise I'll look
elsewhere, at least in the long run.
(On a slightly related note, one thing that I really, really like in LO
and always have missed in MS Office is the ability to use regular
expressions for search and replace... in a sense, that's also a sort of
powerful automation feature!)
@Tom: wishing for a reliable and powerful macro language is NOT asking
for an MS clone!
Jon
Hi
Fair points! Yep, Jon and Pedro are right that a lot of stuff can be
automated more easily by using macros and M. Fioretti is right that even
stuff that might be better done by other means is probably easier for "the
average user" to do with a macro. As for the proliferation of macros for
MSO i'd say that is an argument in favour of more people publishing more
Extensions but also for translations or redesigns of those for LO (and for
AOO and AndroOO if possible)
Regards from
Tom
Hi
I agree with that.
However, even with MS Office i have very rarely met anyone in any of the
offices i've worked in ever found anyone able to write or edit macros, even
using their macro-recorder. We have run tons of training programmes for
people and sent people off to external training courses and none of them
understand macros. The couple of times i have seen macros being used they
have been created by people outside the organisation and the organisation
has then been locked-in to using a specific version of MS Office. For the
1 or 2 where i had been able to reach the external consultant who wrote the
macros they did have coding skills and could have written the same thing in
a couple of different languages but were restricted by the brief.
I've also been sent documents that appear to have macros or link to
data-sources but those macros don't appear to do anything. They just give
the impression that i need to run them in order to see the document but
actually nothing seems to happen.
Just because a thing is easy or easier doesn't mean it can be done. Also
it doesn't mean it should be done.
Regards from
Tom
First, no offense taken; I am hard to offend, especially when you are polite
You are certainly correct that I did restate some of what you said. In fact, you also said something in your article that I danced around, and, it is probably the most important point. And that is....
There is no macro language specification.
Even if there were a macro language specification, it still would not help unless that macro specification included not just the language semantics, but, also, commands used to manipulate the document and to interact with the program in general. When I hear "language specification", I never think about specific things to externally control a program. So, they would also need to specify an API usable to manipulate documents, switch between documents, etc.
Pedro wrote
The fact that the VBA is for Windows (and Mac?) is not related to locking
people in. VBA is a scripting language shared by all MSO programs to allow
automation.
I disagree. As my response upthread indicates, a macro language is designed
to allow access to an API i.e., an implementation-specific method of
manipulation that has nothing to do with interoperability, portability, or
file format specifications.
Pedro wrote
I think you are being an Open Source fundamentalist. Creating and using
macros doesn't drag you to the dark side of the force...
No. But as Michael Meeks indicated (also linked upthread) it does make
interoperability, portability, and transitioning from one product to another
/significantly/ more difficult.
Best wishes, Owen.
Hi Owen
Owen Genat wrote
Pedro wrote
I think you are being an Open Source fundamentalist. Creating and using
macros doesn't drag you to the dark side of the force...No. But as Michael Meeks indicated (also linked upthread) it does make
interoperability, portability, and transitioning from one product to
another /significantly/ more difficult.
Yes, it does. So the only step forward is for the FLOSS community
(LO/AOO/etc) to SOLVE it. Some automated tool to convert Macros from VBA to
BASIC has to be implemented, otherwise this will ALWAYS be an obstacle.
Quoting the article on the Toulouse migration to LibreOffice you posted in
another email: "Exemptions were granted to allow some staff to keep
Microsoft Word on their desktops together with LibreOffice [...] The
exemptions were given because some Word macros and sophisticated Excel files
could not be reproduced in LibreOffice or other open source productivity
suites."
Regards,
Pedro
Hello everyone,
Hi Owen
Owen Genat wrote
Pedro wrote
I think you are being an Open Source fundamentalist. Creating and
using
macros doesn't drag you to the dark side of the force...
No. But as Michael Meeks indicated (also linked upthread) it does
make
interoperability, portability, and transitioning from one product to
another /significantly/ more difficult.Yes, it does. So the only step forward is for the FLOSS community
(LO/AOO/etc) to SOLVE it. Some automated tool to convert Macros from
VBA to
BASIC has to be implemented, otherwise this will ALWAYS be an obstacle.Quoting the article on the Toulouse migration to LibreOffice you posted
in
another email: "Exemptions were granted to allow some staff to keep
Microsoft Word on their desktops together with LibreOffice [...] The
exemptions were given because some Word macros and sophisticated Excel
files
could not be reproduced in LibreOffice or other open source
productivity
suites."
Let us leave alone the fact that macros are not standardized and are user generated scripts the rely on application logic only creating a source of endless pains in migrations, Novell had been working on a project to "translate" macros from VB to Starbasic. It did have some results with simple ones but it did not prove satisfactory.
Instead of making demands on thibgs that are supposedly blockers for adoption (and when these are solved there is automatically a new blocker because it is not about features parity as it is about the will to migrate) the real question is: who is readybto pay to implement this or that feature, knowing that often it will cost several thousands or tens of thousands of euros/dollars?
The question I am asking is not only about LibreOffice, it concerns every FOSS out there and a good example is OpenSSL. So when reading about Toulouse I feel happy but somewhat upset as to my knowledge they saved 1 million but never thought about fund any LibreOffice devloper for support. And yet they have the guts to make statements about we ought to do? I wonder what they would do if people stopped paying taxes and made demands to them everyday...
Cheers,
Charles.
Hi Charles-H.
Charles-H. Schulz wrote
Let us leave alone the fact that macros are not standardized and are user
generated scripts the rely on application logic only creating a source of
endless pains in migrations, Novell had been working on a project to
"translate" macros from VB to Starbasic. It did have some results with
simple ones but it did not prove satisfactory.
Maybe it needs more money/time invested?
Charles-H. Schulz wrote
Instead of making demands on things that are supposedly blockers for
adoption (and when these are solved there is automatically a new blocker
because it is not about features parity as it is about the will to
migrate) the real question is: who is ready to pay to implement this or
that feature, knowing that often it will cost several thousands or tens of
thousands of euros/dollars?
That is a very good point. Unfortunately people are naturally resistant to
change. Any excuse is a good reason NOT to change. That being said, if
promoting migration to LO/AOO/etc is a goal for TDF/Apache/etc then there
should be a joint effort to remove barriers...
I also agree that migration to FLOSS is sometimes sold to managers as low
cost because they don't intend to spend money/contribute man-hours to the
projects they are "borrowing" the software from.
It does seem that thousands of dollars/euros would be a fair contribution
when the migration of a single town caused a saving of a million euros...
Cheers,
Pedro
Hello Pedro
Hi Charles-H.
Charles-H. Schulz wrote
Let us leave alone the fact that macros are not standardized and are
user
generated scripts the rely on application logic only creating a
source of
endless pains in migrations, Novell had been working on a project to
"translate" macros from VB to Starbasic. It did have some resultswith
simple ones but it did not prove satisfactory.
Maybe it needs more money/time invested?
Perhaps. I don't have the numbers but Novell at the time invested in this for something like 4-5 year and put several people on it so it was never exactly a side show either...
Charles-H. Schulz wrote
Instead of making demands on things that are supposedly blockers for
adoption (and when these are solved there is automatically a newblocker
because it is not about features parity as it is about the will to
migrate) the real question is: who is ready to pay to implement thisor
that feature, knowing that often it will cost several thousands or
tens of
thousands of euros/dollars?
That is a very good point. Unfortunately people are naturally resistant
to
change. Any excuse is a good reason NOT to change. That being said, if
promoting migration to LO/AOO/etc is a goal for TDF/Apache/etc then
there
should be a joint effort to remove barriers...
You raise an important point. I think what TDF is interested in -notice the nuance here- is ensuring that the businesses who contribute to LibreOffice get revenues on migrations and LibreOffice related project. This is what we are trying to achieve for instance with professional certification. As for the rest we can work with other ODF implementors on technical issues, solving quirks, etc. Promoting migrations would be vague I guess...
I also agree that migration to FLOSS is sometimes sold to managers as
low
cost because they don't intend to spend money/contribute man-hours to
the
projects they are "borrowing" the software from.
It does seem that thousands of dollars/euros would be a fair
contribution
when the migration of a single town caused a saving of a million
euros...
Here's my theory on this based on 10 years of consultancy in these matters. It is fair to assume that a migration to FLOSS ends up costing 20% less than its equivalent in proprietary software. Why? How do I come up with that figure? 20% is the average cost of software licence compared to the rest of the costs: service, support, training... You still should pay for those with FOSS. You can of course go a little cheaper but if you are really cheaper than you are either forgetting something and not doing it right or someone else is subsidizing these costs.
To me the notion that with free software you will pay zero or close to zero is dangerous. Unfortunately it is a popular one, oddly enough more popular among corporate and public sectors than among citizens themselves.
Best,
Charles.
Charles-H. Schulz wrote
Maybe it needs more money/time invested?
Perhaps. I don't have the numbers but Novell at the time invested in this
for something like 4-5 year and put several people on it so it was never
exactly a side show either...
This 2007 OpenOffice.org presentation seems to indicate the effort mentioned
by Charles-H.:
http://www.openoffice.org/marketing/conference/presentations/VBA_Macros_-__Interoperability_380.pdf
Seems to involve the merging(?) of helperapi from Sun (written in Java for
Word/Excel) and oovbaapi from Novell (written in C++ but for Excel only).
Presumably Noel Powers would be able to provide greater detail as to what
the effort achieved back then. Both tools remain in the source tree and are
still seeing updates although to what degree / effect would require a
developer to clarify.
Best wishes, Owen.
Hi
This looks very interesting! I had no idea people were working on such
interoperability for macros and so i had just assumed it was impractical.
Great to hear that part of the project is still being worked on too!
Regards from
Tom