Jörg Wartenberg wrote:
Hi Jürgen,
would it be possible to implement this Wrapper API in StarBasic? I'am
of course it is, you can implement it as a Basic library and can deploy
this new library as a UNO package.
But we should combine our efforts. Too many different approaches would
totally confuse the end user.
Juergen
thinking about something like small StarBasic include files for each VBA
function. This would allow the user, to read the code behind the wrapper
API. (This wrapper code could be collapsed in the default view of the
StarBasic IDE, to maintain readability).
If the user want modify the imported VBA code, he has already UNO API
code to start from.
Regards Jörg
Jürgen Schmidt schrieb:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
