I did find something out. When I downgraded from Apso 1.3.3 to 1.3.2 everything is working fine.
Well, isn’t that something!
OK I just learned something, I did some experimenting and here is what I found. First I updated to 1.3.3, and then select Options:
This will open the Options window:
I manually added notepad++. Then clicked OK. Now I am able to use the latest version APSO
1 Like
Does this mean that the APSO console only starting working for you after you set the editor in the settings?
So I mentioned beofre that for me, 1.3.2 works by default. When I upgraded to 1.3.3.2, it resulted in the errors that you saw above. To get around this, I had to set the editor in the options window. This works for LO 24 64bit on Win10. It also works in LO7.6 64 bit on Linux Mint. However for LO 24 this does not display any error, but it does not call the specified editor, which for me is KWrite.
sources/python/apso.py · master · Jean-Marc Zambon / apso · GitLab is definitely a bug: the condition is erroneous, simply a string literal 'Linux', which is always true, instead of the intended elif platform.system() == 'Linux':. This code is only called when there is no explicit editor set in the extension; that’s why it possibly isn’t noticed by others, and why the manual choice of the editor fixes it for you. Indeed, trying to call FreeDesktop’s xdg-open is not expected on Windows.
You might want to file a bug report on the APSO site.
4 Likes
Looks like @Jean-Marc Zambon was on the way to introduce match case
def opendefaulteditor(filepath):
import platform
match platform.system():
case "Darwin":
logger.debug("Detected system: macOS.")
sub_call(('open', filepath))
case 'Linux': # linux variants
logger.debug("Detected system: Linux.")
sub_call(('xdg-open', filepath))
case 'Windows': # Windows
logger.debug("Detected system: Windows.")
webbrowser.open(filepath)
case _:
logger.debug("Detected system: other.")
webbrowser.open(filepath)
2 Likes
Ok i will wait for the update
what kind of programmer are you?
VBA, java, LO Basic, python, SQL(oracle, firebird, postgres,etc), a few things more.
Oh…I see. A real Jack of all trades
rofl
So I updated to Apso 1.3.3.3 on my windows 10 laptop. Here is the full info:
Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_US); UI: en-US
Calc: CL threaded
Here is the info for APSO
With options:
So I have python macros both inside and outside of my documents:
Now when I try to open a file from “My Macros”, the file opens normally. However when I open a macro embedded in the document, I get the following error:
Traceback (most recent call last):
File "E:\Program Files\LibreOffice\share\uno_packages\cache\uno_packages\lu51483nbf.tmp_\apso.oxt\python\apso.py", line 921, in exec_edit
url = tempfiles[node.uri]
KeyError: 'vnd.sun.star.tdoc:/2478281483560/Scripts/python/ModuleDB.py'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "E:\Program Files\LibreOffice\share\uno_packages\cache\uno_packages\lu51483nbf.tmp_\apso.oxt\python\apso.py", line 966, in _create_tempfile
self.adddoceventlistener()
File "E:\Program Files\LibreOffice\share\uno_packages\cache\uno_packages\lu51483nbf.tmp_\apso.oxt\python\apso.py", line 1008, in adddoceventlistener
doc_id = "{}:/{}/".format(self.DOC_PROTOCOL, doc.RuntimeUID)
AttributeError: RuntimeUID
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "E:\Program Files\LibreOffice\share\uno_packages\cache\uno_packages\lu51483nbf.tmp_\apso.oxt\python\apso.py", line 926, in exec_edit
url = self._create_tempfile(node)
File "E:\Program Files\LibreOffice\share\uno_packages\cache\uno_packages\lu51483nbf.tmp_\apso.oxt\python\apso.py", line 980, in _create_tempfile
raise ErrorAsMessage("_create_tempfile\n\n"+str(e))
uno_component.ErrorAsMessage: _create_tempfile
RuntimeUID
?? Im just confused about this huge RuntimeUID ??
Have no idea about that.
if I had a script that creates 10 odf-documents every second, each with a new UID, it would take around 7800 years to get to this UID!
So would you say this large number is the source of the error?
How am I supposed to know who or what is going crazy on YOUR system?
1 Like
I have seen many times that if an error occurs, LO stops numbering the RuntimeUID sequentially.
Well, back to 1.3.2
Especially when you are ROFL all the time.