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