Hi there,
the threads relating to macro recording abilities of OOo are very
interesting. I have been somewhat puzzled about the conclusion that OOo
should *not* have a macro facility at all and that the existing ones
should be removed. The reason being that it would be "too much effort
for the expected benefit" (see below)!
Now this is puzzling for me for various reasons, especially in the
context of typical "end-users" using OOo. Without a macro facility they
have *no* chances whatsoever to be able to automate recurrent (business
process) tasks on their own. They either have the choice of repeating
(possibly cumbersome) over and over all the steps necessary to come up
with a recurrent document, or they need to find someone who would be
able to create a program for them to automate the recurrent functions
they need. And here the simple truth is: there is almost no-one around
who would have the *slightest* idea of how to automate/program OOo.
Looking further for professionals is difficult to find ones, and if you
find ones then you must be very, very lucky, if they have free resources
that they sell/rent for an affordable price. Or with other words: forget
it, rather repeat recurrent tasks by hand over and over again!
This scenario does not look like an attractive or future safe one to me.
Especially, if you compare this with Microsoft's Office (MSO) where it
is extremely easy for end-users to record macros, in practice this is a
no-brainer for them! As a result it is a) easy and b) cheap for MSO
customers! Also, recorded macros can be adjusted quite easily, if an
end-user has a coarse understanding of programming.
Not seriously planning for a macro-recorder facility is a *quite* a
*deadly* strategic error IMHO. MSO runs rings around OOo in a very
important application segment! And MSO will be able to do that
eternally, given any misisng plans to implement a macro recording
facility for all modules. Rather than tackling this incredible omission
immediately to fill this incredible "hole", the undisputed conclusion
seems to be, "well we can't do it now, so we don't do it, and best, we
ought to remove the existing macro recording as it was not done the way
it should have been done from the beginning".
Again, for an end-user perspective this is a glaring hole, making MSO
truly much more attractive for their own daily work. Hence OOo *must*
get macro-recording "as it should be done" for *all* modules as quickly
as possible, if OOo should win and take over the hearts of the OOo
users, especially the huge group of "end-users" sitting in all of these
departments that should be migrated from MSO to OOo!
Just my 2 cents.
---rony
P.S.: If designed and done right, then macro recording should be
feasible for interacting with/using any UNO service object in a language
neutral manner, such that the generable macros could be created for any
of the desired target languages of the users, OOo Basic, Python, Java,
BeanShell, ooRexx, and the like.
E.g., if I knew what the initial environment was (already there for
macros) and what interactions (API invocations with used arguments) took
place, then I would be able to (easily!) create from that an ooRexx
program that would be able to "replay" all those API invocations. I am
sure that Andrew would know and be able to do the same vor OOo Basic,
and everyone else acquainted with UNO and another scripting language
would be able to generate the appropriate code in their chosen scripting
language.
Mathias Bauer wrote:
> Andrew Douglas Pitonyak wrote:
>
>
>> Even better, will a new and improved macro recorder be implemented? I do
>> not remember seeing one in any road map, but I might have missed it.
>>
>
> A new+improved macro recorder (I assume you mean a recorder that uses
> the "real" API and not the dispatach API) would be possible only by
> completely rewriting all "glue" code between the controls and the
> document core. This is very unlikely to happen.
>
> Why is that so? A recorder can record only API calls that are "played".
> The only API calls that currently are "played" are the dispatch API
> calls. If you wanted other code to be recorded we would need to use
> ("play") them in the code executed by e.g. the code that is executed
> when a menu or toolbar control is selected.
>
> And while we are at it:
>
>
>> Kálmán Szalai wrote:
>>
>>> Thank you for the information.
>>> Are you planning to reimplement this part and make it available under
>>> Draw/Impress?
>>>
>
> There are no plans to implement that. If I had the choice I never would
> have done it for Writer and Calc also as the current macro recorder is
> not what people really want and the "real" thing is just too much effort
> for the expected benefit. The resources we invested for that can be
> used better for more important things.
>
> Ciao,
> Mathias
>
>
