Mathias Bauer wrote: > Rony G. Flatscher wrote: > >> But there must be a mapping available which maps from UNO to C++ as >> otherwise the C++ code would not be invocable via UNO? >> > Of course: this is the Dispatch API! The UI elements use die Dispatch > API to call a method in a UNO object implementing > com.sun.star.frame.XDispatch. This is the only UNO based call involved. > The implementation of this object only uses pure C++ calls inside, > nothing based on UNO APIs, neither in-process nor remote (urp). > But then, wouldn't this also mean that this Dispatch API is excercised by all OOo modules then, including Draw/Impress, or is it the case that for using that API some of the module-dependent (C++ implemented) UI elements still need to be programmed accordingly?
> But we are talking about recording "the other" API that an experienced > OOo API developer would use to perform the same task. And this API would > be a completely different one. > Right. > If I have some time I will try to put some code snippets into the wiki that > should demonstrate this. > Would be very interesting in any case, but your points seem to be already very clear. >> A reverse mapping should be establishable then as well in this case, even if >> that is a 1:N >> mapping (i.e. a C++ function/method gets invoked from different UNO >> types), it would at least allow for narrowing down the UNO types, and it >> could be possible that from the context one could even narrow them down >> further. >> > > The reverse mapping that we can do is what the current macro recorder does: > all received "dispatch()" calls are recorded. > Hmm, would it be conceivable then to come up with a static table of dispatchable user-actions with a sequence of UNO API invocations that would be needed to be excercised such that for recording purposes this list could be used in addition, recording the values of arguments and results and so on. Or with other words, for every dispatch have an independent, alternitve thread of creating UNO pseudo-code necessary to arrive at the same functionality, stating pre- (which UNO objects, methods, argument values) and post-conditions. Maybe even including branch statements, or with other words, small (commented) pseudo-code segments that could be used to map to a concrete language later on. Either being editable to correct or supply addtional code/information. Even if it is not perfect and may contain omissions or incomplete information it may generate UNO based code that needs a little bit of "massaging", it would be so much more and a starting point that really may drive up productivity. (Obviously looking for a Pareto solution, i.e. 20% effort for covering 80% of the needed functionality, leaving the missing 20% to the UNO/OOo savvy programmers.) Power end-users would be able to create that skeleton then rather easily, needing UNO/OOo acquainted programmers to turn it to a running macro. >> Ceterum censeo, macro recording ... >> :) >> > > ... esse delendam? ;-) > ... esse implementam ! :-P Regards, ---rony
