Re: [discuss] Incubator for vba macros

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Incubator for vba macros

Laurent Godard-3
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

--
Laurent Godard <[hidden email]> - Ing?nierie OpenOffice.org
Indesko >> http://www.indesko.com
Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org
Livre "Programmation OpenOffice.org", Eyrolles 2004

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [discuss] Incubator for vba macros

Juergen Schmidt-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [discuss] Incubator for vba macros

Jörg Wartenberg
Hi Jürgen,

would it be possible to implement this Wrapper API in StarBasic? I'am
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[discuss] Re: Incubator for vba macros

Noel Power-2
In reply to this post by Laurent Godard-3
Hi Laurent,

I try to respond inline to your points

Laurent Godard wrote:
> Hi Noel
>
> Thanks for your proposal and your presentation
Thnks,
>
> 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.
One of the goals is to improve/add to those existing compatibility efforts.
>
> 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.
>
A VBA-like API is necessary for allowing VBA macros to run, sure a
secondary affect is that the interopability API will also now become
available if someone wishes to use it. I don't see this as a problem.
The OOo API is although very powerful, it is also very find grained ( &
some people would say it's too fine grained & developer-centric rather
than scripter-centric ) On the other hand an api that provides
interoperability capabilities is a higher level abstraction of the OOo
API. I don't see the 2 apis as competing or mutually exclusive rather
that they compliment each other, they are different tools for doing
different tasks. And of course the interop api is built on top of the
existing API

> How does this interact ? Is a VBA macro allowed to mix both API ? Is
> python script allowed to use VBA objects and OOo objects ?
The API is an UNO api, therefore can be leveraged by any scripting
language, as for mixing the API again I don't see any barrier there.
> Are VBA macros only restricted to MS File format (i see no technical
> reasons for this)
Not sure what you mean here, a new API ( or set of APIs) will exist, its
possible that access to that api could be limited ( e.g. to an xls file
only ) but I don't think that is a good idea, imo freedom of choice is
better.
>
> For me, at the end, it will be the end of any scripting language except
> VBA one. Forget OOoBasic, python, Beanshell or javascript.
Wow, I don't know how you could come up with such a statement. There is
no new scripting language being implemeneted just:
* an API implementation ( wrapping the existing API )
* some magic in OOobasic that does some syntatic sugar coating that
helps VBA code run within easier in OOo.

I don't see how that can affect someones choice of scripting language.
If someone wants to use java or python or whatever, normally they make
that choice based on what scripting language they know best, what the
language offers them etc. Each scripting language has different
benifits/strenghts but each scripting language mentioned has access to
all of the uno API functionality including the new interoperability stuff.

> 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.

Thats just reality, if you want people (especially organisations) to
migrate to OOo, you have to make it easy for them especially in terms of
collateral that they have in terms of legacy documents etc. Facilitating
that is a primary goal.

>A lot of documentation exists and we will be asked more and
> more to implement VBA subtilities
We don't know what will happen so who can say what kind of requests will
be made. But is this any different to any other aspect part of OOo?
Where requests for new features of enhancements take place, they have to
be dealt with individually and evaluated in terms of importance,
usefulness etc.
>
> 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 ?
Well I'm not a lawyer so I can't really comment other imo than it seems
to me that this area is just as grey ( if it is grey ) as other parts of
OOo where there are "striking" similarities to "other" office products
in terms of ui, usage patterns,scripting language and objects. And
still, just to be clear, there is no interpreter implementation other
than the existing OOobasic.
>
> 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)
nah, can't see that's benificial, free software, freedom of choice...
> - 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
Well hopefully some of the above eases your concerns ( maybe not ), in
anycase I'm just as open to discussion on same
>
> Regards
>
> Laurent
>

Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [discuss] Incubator for vba macros

Juergen Schmidt-3
In reply to this post by Laurent Godard-3
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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discuss] Re: Re: [discuss] Incubator for vba macros

Michael Meeks-2
In reply to this post by Juergen Schmidt-3
Hi Jurgen,

On Tue, 2005-12-13 at 09:24 +0100, Jürgen Schmidt wrote:
> 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),

        Of course - there is no argument as to which API is 'better' per-se;
personally I only learned the StarBasic API by reading the
http://documentation.openoffice.org/HOW_TO/various_topics/VbaStarBasicXref.pdf
Vba to Starbasic cross-reference guide (which was much appreciated
incidentally).

> 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.

        You forgot the macro recorder; most of the VBA macros we analyse show
serious signs of being macro record/cut/paste/adapt; almost no flow
control, nothing complex in them :-). But sure - no-one is proposing
that people start writing new macros using the VBA object model vs.
OO.o.

> 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.

        Of course that is valuable work - but outside the remit of the proposed
incubator - which is really an interoperability project: yes, almost
certainly we will never reach 100% compatibility - lets face it that
would implicitely involve 100% feature parity with MS Office since ~all
features are exposed to VBA - which seems unlikely. However - I'm
certain that we can provide something extremely useful to lots of
people, that will help them migrate to OO.o.

> 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.

        Well - it's encouraging that you're not opposed :-) thanks for your
input & insight - much appreciated,

        Regards,

                Michael.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [discuss] Re: [dev] Re: [discuss] Incubator for vba macros

G. Roderick Singleton-2
On Tue, 2005-12-13 at 12:10 +0000, Michael Meeks wrote:

> Hi Jurgen,
>
> On Tue, 2005-12-13 at 09:24 +0100, Jürgen Schmidt wrote:
> > 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),
>
> Of course - there is no argument as to which API is 'better' per-se;
> personally I only learned the StarBasic API by reading the
> http://documentation.openoffice.org/HOW_TO/various_topics/VbaStarBasicXref.pdf
> Vba to Starbasic cross-reference guide (which was much appreciated
> incidentally).
>

Thanks. I was about to mention the existence of this document.


[snipped]
--
PLEASE KEEP MESSAGES ON THE LIST.
OpenOffice.org Documentation Co-Lead
http://documentation.openoffice.org/ 


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]