Hi,
i agree 100% with Laurent, it means a second API and that of course is
probably not what we want. But the question is how we can address all
the VBA programmers to migrate to OpenOffice and it's complete different
API model. Does it make sense to have a migration layer on top of the
existing API for exactly the VBA and Basic programmers in general?
I am not sure, the main API focus will be still on the UNO API and we
will go forward with this approach. The VBA wrapper API is implemented
in UNO as well and makes use of the existing API. That means it would be
one abstaction layer higher and of course one indirection more which
means slower than the normal API.
From my point of view this kind of wrapper API should be used for
migration only and everything else should use the existing UNO API. It
can be designed as an extension package and people who want use it can
install this package optionally for example.
I am flexible when we think we need it i am willing to support it. But
of course the VBA API is not better than our existing API (far from it),
it has only the advantage that it is well known, has great IDE support
(MS Dev Studio), is well documented (thousands of books) and many many
people use it.
I personally believe that we will never reach a 100% roundtrip with
macros and i would concentrate on the existing API and improvements in
this area. Some of our existing APIs should be redesigned or improved by
using the UNO ease of use features and a lot of other things can be done
to simplify the development of our existing API.
so no vote from my side, no +1 and no -1, only the offering to support
the project on the level of the existing API.
Juergen
Laurent Godard wrote:
Hi Noel
Thanks for your proposal and your presentation
I'm aware that VBA macros are a problem on a migration and something has
to be done. So you're proposal is welcomed
Nevertheless, I'm afraid that using VBA paradigm inside OOo will more
hurt than solve the problem. VBA has 2 parts : the language and the objects
I'm not talking about the syntax here. Some compatibility efforts have
been done in this directon and can be improved.
The problem, imho, is on the API level
Giving VBA support as you propose is implementing a new API for objects.
You will then have two ways for defining objects : the OOo API one, The
MS VBA one. It will be more difficult to understand things as these two
objects, will have difference : a VBA cell is different tha an OOo one.
How does this interact ? Is a VBA macro allowed to mix both API ? Is
python script allowed to use VBA objects and OOo objects ?
Are VBA macros only restricted to MS File format (i see no technical
reasons for this)
For me, at the end, it will be the end of any scripting language except
VBA one. Forget OOoBasic, python, Beanshell or javascript. VBA is widely
spread due to MS file format domination. Many people do know how to
create VBA macros and then it will end with a big proportion of this
language. A lot of documentation exists and we will be asked more and
more to implement VBA subtilities
But, VBA is not free ! OOo Project has no influence on its specification
and it can be changed without any warning (look at the difference
between MsOffice versions)
Moreover, what about legal issues ? Are we sure there are any patent on
this ? Are we allowed to implement an interpreter ?
Noel, I'm really enthousiastic by you project in a technical point of view.
But, i have to say -1 for the resons i gave, unless we build some
policies like (only proposal, ideas not worked)
- restrict vba to ms office file format (not opendocument or addons)
- translate the VBA source code to OOo API to only have to deal with one
model
So -1 for me
But totally open to discussion
Regards
Laurent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
