Forum rules
For sharing working examples of macros / scripts. These can be in any script language supported by OpenOffice.org [Basic, Python, Netbean] or as source code files in Java or C# even - but requires the actual source code listing. This forum is not for asking questions about writing your own macros.

When I execute Python macro even through Script Organizer for Python entry in the main menu, all script providers are instantiated. All language engine for macro are initialized and script provider for each context for all language engine are instantiated. Because script organizer uses css.script.browse.theBrowseNodeFactory singleton to create MACROORGANIZER view and to load script nodes.This does not happen when I execute Python macro from menu item. I wrote a toy, alternative script organizer dialog for Python.

Thanks for mentioning about it. I forgot it. But if you use this alternative dialog, you do not need ModifiedPythonScriptProvider anymore except for editing function.

If you want to execute edit function with this, change ENABLE_EDIT field of OrganizerDialog calss to True and implement exec_edit instance method for your needs. For user and share macro, URL to real file can be get with node.uri and convert it to system path and then pass to your favorite editor. For macro embedded in a document, it can be like that watching timestamp for temporaly file created with macro content and updating embedded file with modified data. But substituting embedded file with existing file is better choice, in my oppinion. Debug function is prepared to implement by the user also if you have a tool for that. But writing Python macro as RPC script and debugging is easier way to do that.

Please, edit this thread's initial post and add "[Solved]" to the subject line if your problem has been solved.Apache OpenOffice 4-dev on Xubuntu 14.04

I recently discover this script from Hanya, which I find just awesome !This script, IMHO, deserves far better visibility. As a start point, I made some tweaks in the code and packaged it in a extension for easier distribution.

Changes in the code are minor:- localisation (by now EN, DE, FR and IT) [added HU thanks to Zizi64];- two new menu commands "copy to document" and "export" from someone else document (code reused froma Hanya's);- quick (and dirty) implementation of "exec_edit" so that script can be opened by the system default editor associated with py files (it would be nice here to merge EditorKicker code).

The extension adds a new element "Organise python script" under menu Tools/Macros with default shortcut Alt+Shift+F11.

Note that all this is only "packaging work", core remains Hanya's code.

Tibor Kovacs, Hungary; LO4.4.7, LO5.4.6 on Win7x64Prof.PortableApps, winPenPack: LO3.3.0-LO6.0.2 and AOO4.1.5 Please, edit the initial post in the topic: add the word [Solved] at the beginning of the subject line - if your problem has been solved.

I merged Hanya's EditorKicker code and the corresponding lines of his ModifiedPythonScriptProvider.

The new release of the APSO extension has therefore some new features :- a setting page (optional) for providing a custom text editor and some file opening parameters (i.e. EditorKicker);- macro opens to the right line provided the above settings are given;- error dialogs give direct access to the erroneous line and offset in case of syntax error (again provided the above settings are given);- quick edition of embedded scripts is possible (but only in the context of APSO extension);- improved error dialogs in case of non-ascii message;- terminology fits the default organizer one;- the document property AllowMacroExecution is evaluated and taken in account before execution.

Some localized strings have been rewritten. Please advise me for any error or suggestion, thanks.

As luck would have it, just today I was looking into running Python Macros and stumbled onto your note. I am very excited to try out your efforts on my system.

APSO extension has now is own page on the LibreOffice extension site

A suggestion if you allow me.

I have only the basics for now.. that means IDLE. I assumed to need to point the extension to the editor. Under LibreOffice > Extension Manager > :: APSO 1.0.0 :: > Options > APSO > EditorKicker > Editor > C:\Python36\Lib\idlelib\idle.bat

Very probable I did something wrong. I am hoping you add a note on how to add the editor of your choice in the extension description notes.

I can't figure out exactly what is the problem with idle command. But it seems to me a bad idea to use it with apso : idle is bound to the system python interpreter, which is different from the bundled version. The system interpreter does not know the uno context : executing or debugging from idle window will not work.If you have Notepad++ installed, it's quite a good option : edit the code, save it and then execute it from LibreOffice.

If you prefer to use python from outside the office process, you'll find usefull informations here as a starting point.

Congratulations to all contributors to this excellent and useful piece of software, *Apso*! It is unlikely that I would have finished my first *Office* macro with *Python* without it!

In these exercitations I have discovered a small problem, that I report here just in case it could be helpful. Whereas when I execute *Organize Python scripts* from the initial *Office* switchboard or from the database initial one (after having opened a database) things work normally, if I launch *Apso* after openning any *database form*, the *Apso* user interface refuses to appear. There are neither error messages nor misbehaviours, just nothing perceptible happens. One can know however that something has happened by the fact that, in spite of it, the auxiliary *apso_utils* become available to the other routines, something that does not happen before it is executed for the first time.

This odd behaviour appears as well in *OpenOffice 4.1.3* as in *LibreOffice 5.2.3* over *Windows 7*, the programs that I use.

Thanks for your contribution. I'll have a look on GitLab.But Apso is a organizer for python macros, I'm no sure at all that the pythonpath folder, which is not intended to contain end user macro, should be seen from there.

Before you make a decision, please go to Menu -> pythonpath example (fr: Exemple pythonpath) and then execute ppath_example.hello(). This python macro imports another module, something I believe many python macro developers will find useful. The alternative is either to store all code in one gigantic file or else duplicate code in multiple files, which becomes difficult to maintain.

OpenOffice Basic has the capability of calling code from another module, so why shouldn't APSO provide that capability as well?

There are also behind-the-scenes changes such as making the APSO menu code easier to maintain.

I never meant that pythonpath should not be used! I just said that, imho, it doesn't need to be visible within Apso. Importing from other modules has always been and will always be possible.In the other hand, what would you do with embedded scripts ? It's not impossible to import from embedded pythonpath, but not straightforward, and maybe should not be encouraged in this specific case.I'm not stubborn, but still asking to be convinced...

I'm not sure I fully understand. In the first paragraph, you stated that importing from other modules is possible. However, APSO cannot currently view or edit these modules, correct? So that makes it practically impossible to do from within APSO.

For example, let's say that under My Macros (either user or system location), I use APSO to create a file called writer.py for Writer macros, and a file called calc.py for Calc macros. Now, I need to create a helper function that is used by both. This is a setup that I believe many beginning macro users may want. With the currently released version of APSO, this is not possible.

With the new changes that I propose, APSO can be used to create the pythonpath folder and module so that the helper function can be imported from both writer.py and calc.py.

Regarding embedded scripts in a document, I do not remember finding a way to do this for pythonpath. You mentioned that it's not impossible. Would you care to provide a link or more information? I do not have as much experience with embedding in documents. Most of my work has been with developing extensions or with user-location macros ("My Macros").

j.kornelsn wrote:Regarding embedded scripts in a document, I do not remember finding a way to do this for pythonpath. You mentioned that it's not impossible. Would you care to provide a link or more information?

See code of checkForPythonPathBesideScript function in pythonscript.py file. To make built-in import function of the Python, os.access is used to check the path is accessible by the system IO. So we can not use embedded pythonpath/ in documents.This can be solved by import hook introduced on Python 3.1. Using importlib, we can add custom importer for embedded python macros. But if we add many path to sys.path, some modules might conflict each other.

Please, edit this thread's initial post and add "[Solved]" to the subject line if your problem has been solved.Apache OpenOffice 4-dev on Xubuntu 14.04

j.kornelsn wrote:I'm not sure I fully understand. In the first paragraph, you stated that importing from other modules is possible. However, APSO cannot currently view or edit these modules, correct? So that makes it practically impossible to do from within APSO.

That's correct. Again, I think imported libraries should be developped outside pythonpath and, once in there, should not be edited anymore. But maybe I'm wrong...By the way, once imported, any change to a file in pythonpath will not be taken into acount until it is reloaded or document reopened.

j.kornelsn wrote:Regarding embedded scripts in a document, I do not remember finding a way to do this for pythonpath. You mentioned that it's not impossible. Would you care to provide a link or more information?

I gave an example here in the french forum.The idea is to take advantage of the implicit zipimport mechanism, something like this (document needs a location):

That is an interesting example. @hanya, thank you for the additional information as well. But I agree, using such an approach for embedded pythonpath is not something that APSO should encourage.

I think imported libraries should be developed outside pythonpath and, once in there, should not be edited anymore.

Why not? As you said, all that is required is to restart OpenOffice or otherwise force the module to reload. I have developed many macros this way.

However, I think I see now why you are saying this. In my background as a developer, structured design in applications is fundamental. Python makes it easy. This is perhaps a different philosophy from how APSO was designed, which if I understand what you are saying, is intended as a simple tool to create small macros, not a complete solution.