Apache OpenOffice (AOO) Bugzilla – Issue 85298
Java macros assigned to a toolbar button cannot be executed from there
Last modified: 2017-05-20 10:55:25 UTC
When you assign a Java "macro" to a toolbar control, the Scripting Framework throws an exception and can not invoke the method: A Scripting Framework error ocurred while running the Java script [MyClass.myMethod] Message: ScriptResolver.getProxy: Can't find method: myMethod:MyClass.myMethod(com.sun.star.script.provider.XScriptContext, java.lang.Short) The Java methods get invoked with a second, extra, and unexpected, argument of type Short.
Created attachment 50911 [details] ODT with a toolbar invoking Java methods
Happens ONLY with Java, not with JavaScript nor BeanShell
(took the liberty to make the summary more concise) fs->ab,cd,npower: Not sure who is to blame for this ... When the user clicks the toolbar button, then the protocol handler for script URLs (scripting/source/protocolhandler/scripthandler.cxx) is invoked (ScriptProtocolHandler::dispatchWithNotification). The framework passes an argument "KeyModifier" to this method, obviously to allow the user to press modifier keys when executing the toolbar slot. However, the ScriptProtocolHandler implementation passes all the arguments it gets (except "Referrer") to the XScript::invoke method (after stripping the name). Thus, the actual script is invoked with an additional parameter of type short. Unless all other script languages, Java is strictly type-safe, so in fact a Java method taking an XScriptContext and an additional short is searched - and not found. I could imagine different solutions: - let the ScriptProtocolHandler also strip the "KeyModifier" argument. This might, in theory, break existing scripts in other script languages - the the JavaScriptProvider (resp. its XScript implementation) fall back to a method without the additional "short" parameter, if it doesn't find such a method. This is kind of magic, and probably hard to maintain. - add some additional "invokeWithContext" (or so) method to XScript, which takes an explicit "KeyModifier" (and maybe more) parameter. Might be overkill. - Declare this as feature: If you want to execute your Java code from within a toolbar, then add a method taking an additional short parameter. This is somewhat hacky IMO, since the fact that the short is a KeyModifier is known in the toolbar and in the final Java code only, inbetween, it is only transported as mere short. This means that if, for whatever other reasons, other shorts are transported, this might end up in the method which feels responsible for the "KeyModifier" parameter. Not really nice.
>Not sure who is to blame for this ... I think I remember doing this </me hides> or if not actually inserting the code lines at least I recall this scenario. IMO this is an error and the "KeyModifier" should NOT be passed as a script argument. The only reason I would think it SHOULD be transported as an argument would be if in the days of old ( pre-scripting framework ) that a basic script would also get this argument, does anyone know if this is the case ? ( or are the toolbar macros a new-ish feature ), this would be the only reason to let this scenario remain. If it is the case, i.e. that the 'KeyModifier' should not been passed, then I am afraid that yes it is possible that someone may depend on this undefined behaviour, however imo it still should be removed.
STARTED 3.x
.
Reset assigne to the default "issues@openoffice.apache.org".