Issue 85298 - Java macros assigned to a toolbar button cannot be executed from there
Summary: Java macros assigned to a toolbar button cannot be executed from there
Alias: None
Product: General
Classification: Code
Component: scripting (show other issues)
Version: OOo 2.3.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2008-01-16 16:34 UTC by Ariel Constenla-Haile
Modified: 2017-05-20 10:55 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

ODT with a toolbar invoking Java methods (6.66 KB, application/vnd.sun.xml.writer)
2008-01-16 16:36 UTC, Ariel Constenla-Haile
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Ariel Constenla-Haile 2008-01-16 16:34: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:


The Java methods get invoked with a second, extra, and unexpected, argument of
type Short.
Comment 1 Ariel Constenla-Haile 2008-01-16 16:36:21 UTC
Created attachment 50911 [details]
ODT with a toolbar invoking Java methods
Comment 2 Ariel Constenla-Haile 2008-01-16 16:41:54 UTC
Happens ONLY with Java, not with JavaScript nor BeanShell
Comment 3 Frank Schönheit 2008-01-16 17:41:51 UTC
(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
Comment 4 noel.power 2008-01-17 09:32:01 UTC
>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.
Comment 5 ab 2008-01-25 13:54:07 UTC
Comment 6 Oliver Brinzing 2011-05-25 16:58:54 UTC
Comment 7 Marcus 2017-05-20 10:55:25 UTC
Reset assigne to the default "".