Issue 113481 - Cannot call Python macro from the command line using URI syntax
Summary: Cannot call Python macro from the command line using URI syntax
Alias: None
Product: General
Classification: Code
Component: scripting (show other issues)
Version: OOO320m18
Hardware: All All
: P3 Trivial with 3 votes (vote)
Target Milestone: 4.2.0
Assignee: AOO issues mailing list
QA Contact:
Keywords: needhelp
Depends on:
Reported: 2010-07-27 21:51 UTC by shrib
Modified: 2015-11-06 13:34 UTC (History)
5 users (show)

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

Patch to add fallback if the frame is not bound to the contrller (2.66 KB, patch)
2014-01-28 13:18 UTC, hanya
no flags Details | Diff
Document contains macro to verify (9.87 KB, application/vnd.oasis.opendocument.text)
2014-01-28 13:25 UTC, hanya
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description shrib 2010-07-27 21:51:10 UTC
I have an Impress presentation file called mydoc.odp. It has a Python script
file called with a function foo in it. I can run the foo function by
doing Tools | Run Macro. However, I am not able to figure out how to invoke the
macro from the command line. I am using Impress 3.2.1 on Ubuntu. These are the
command lines I tried: 

soffice mydoc.odp "macro://mydoc/"
soffice mydoc.odp "macro://mydoc.odp/"
soffice mydoc.odp "macro://mydoc/"
soffice mydoc.odp
soffice mydoc.odp
soffice mydoc.odp

I am able to launch a VB macro in the document using:

soffice mydoc.odp "macro://mydoc/Standard,Module1.Test"

The reply at implied that
this is not supported.
Comment 1 ab 2010-07-28 07:07:27 UTC
Not supporting something is no DEFECT -> FEATURE
and this is no P2 by far (please read the rules) -> P3

ab->cd: This is more Office startup than scripting. Should
this be supported at all? Please have a look.
Comment 2 eric.bachard 2010-07-28 09:07:51 UTC
Comment 3 hanya 2013-12-05 15:18:13 UTC protocol is handled by ScriptProtocolHandler in scripting/source/protocolhandler/scripthandler.cxx.
The script is executed through dispatchWithNotification method but 
XController from the document frame is not valied in getScriptInvocation method at this time.

As the side problem of this issue, when I start soffice with, 
the instance would not exit.
It seems this happens because of the dispatch watcher for calling dispatchWithNotification method of the protocol handler for the script.
When the protocol handler failed to access to the document's script, 
it returned without calling dispatchFinished method of the dispatch result listener.
When I called the method with css::frame::DispatchResultState::FAILURE status, 
the instance of the office finished normally.
Comment 4 hanya 2013-12-05 16:46:24 UTC
css::frame::XDispatch interface is queried to execute the script from the instance 
of the desktop, so its XFrame do not know the controller of the document.

Like SfxMacroLoader::GetObjectShell_Impl for "macro:" protocol, 
SfxFrame could be used to access to the document, it seems.
Comment 5 hanya 2014-01-28 13:18:55 UTC
Created attachment 82414 [details]
Patch to add fallback if the frame is not bound to the contrller

Find current frame from SfxFrame tree or use current document shell if 
the document frame is not bound to the controller yet.
And also, call dispatchFinished if document invocation is not found or 
the execution of the macro is interrupted because of the security settings.
Comment 6 hanya 2014-01-28 13:25:42 UTC
Created attachment 82415 [details]
Document contains macro to verify

The attached document contains BeanShell macro to verify, the body of the document is empty.
Execute the following command: 
> soffice DocWithBeanShellMacro.odt ""
With "Medium" level of macro security: 
- "Enable Macros": "Hello World (in BeanShell)" is written by the macro.
- "Disable Macros": Empty document is shown.
Comment 7 SVN Robot 2014-05-17 10:21:02 UTC
"hanya" committed SVN revision 1595439 into trunk:
#i113481# query script invocation from the current frame when the controller ...
Comment 8 hanya 2014-05-19 12:55:41 UTC
Fixed on trunk.
Comment 9 hanya 2015-11-06 13:34:50 UTC
To confirm the fix, see Comment 6.