LibreOffice Built-In Methods/Functions Where is the Location in Actual Source Code

English
,
#1

Hello,

Please can somebody advise me where in the LibreOffice source code package ie download or github, where is the actual code for defining the built-In functions ie ConvertToUrl etc.

Debugging Basic does not help as it just passes straight through the above statement and I have searched in the actual source code package and I can see references to the above function but not the actual code creating it?

I can also see in the ScriptForge Library something similar but again those are using the original method.

I am referring to LO 24.2.7.2(x86_64) in this instance but if somebody knows where they are in an earlier package or later then that might give me a clue.

Many thanks :smile:

P.R

#2

SbRtl_ConvertToUrl

#3

Hi Mike,

Thanks very much for the quick reply.

Found it in the package (my bad as I was looking for ConvertToUrl as a whole word which I did see in the Method array but missed the SbRtl_ConvertToUrl reference :roll_eyes:) and get it now but can see that this might take a while to get to grips with all the related structs/classes/methods etc to this function as an example but looking forward to it as its been a while with CPP.

Will delve in when I have a few hours spare with no interruptions or could be days/weeks… :smile:

Many thanks.

P.R

#4

You never mentioned the original problem you are solving, so - beyond the explicitly requested code pointer - there’s not much possible to help you.

#5

Hi Mike,

The reason is twofold.

  1. To understand what is going on under the bonnet of LO Basic so maybe add addition functions naively not via LO Basic itself.

  2. To get a better understanding of LO and how it works, especially with the offapi Module etc as sometimes I try and do something in say Python I come across all sorts of problems ie,

from com.sun.star… import …

So running a Python script from within LO would load the related module no problem.

But running the same script from outside of LO but in the same file dir hits an error ie no such module.

Looking at the Python builtin loading module I cannot tell if the related Class is imported from the related .Jar file in \program\classes ie libreoffice,jar with in turn is referenced by unoil.jar or the Class is embedded in a library file elsewhere.

Which is really related to another post I posted a few days ago (not sure if you saw it) relating to a Python error message regards Binary URP.

Many thanks

P.R

#6

The JARs are completely unrelated to Python bridge - they are related to Java.
It’s great that you go the correct path and intend to read the underlying code to debug the higher-level scripting problems. Note that the idea mentioned in your original question, that you are looking at the source as of LO 24.2.7.2, is not the best - we always work with master, and if you decide to hack on some problem and provide a patch, you would have to do that against the current development branch. So I’d suggest you to create a build environment as explained in the wiki, and do all your debugging against a DBGUTIL build.

#7

Hi Mike,

Ah ok, I see, so they are only referenced/used at compile time but not after?

So does that mean e,g when LO Basic is using say createUnoInstance(com.sun…) or createUnoListener(“MouseOnClick_”, “com.sun.star.awt.XMouseClickHandler”) it is not getting "com.sun.star.awt…) from an external library but internal from the module offapi>com>sun>star>awt… as I can only see the interfaces not the actual coding methods and if so where would I find the actual coding methods for say the above example?

I am using 24.2.7.2 because using 24.8+ needs Python 3.9 and Python 3.9 wont run on Windows 7 afaik or at least there may be problems, which is what I am on at the moment.

If I did create a new function etc, I would compile for myself.

I would however, if I did an “Easyhack” (I think that is what they are called) then I would use another machine I have with Win 11 Pro but for the moment,I just haven’t got round to reinstalling everything I have from this machine to that machine in order to develop…lazy!!!

Many thanks

P.R

#8

It seems to me that you think that LibreOffice is based on Java. No, it’s pure C++, and the JARs are only to allow external Java code to communicate with LibreOffice from outside, similar to how PY files are there to allow Python code to communicate with LibreOffice. All the UNO classes (mostly in the com.sun.star namespace) are written in C++; and the naming of the namespace is only influenced by Java (which was the big ~new thing at the time when UNO was created, and which was owned by Sun, as well as OOo at that time) - that influence, making the names feel “Java-ish”, is what likely confusing people.

Ah I see. Well yes, we abandoned Win7 support.

When you use CreateUnoService, you are asking LibreOffice to create a (usually internally implemented) instance of the registered implementation of that service. When you use createUnoListener, you are creating a special Basic object, that can implement just any UNO interface, by delegating respective method calls to the code that you write in Basic.

#9

It seems to me that you think that LibreOffice is based on Java. No, it’s pure C++, and the JARs are only to allow external Java code to communicate with LibreOffice from outside, similar to how PY files are there to allow Python code to communicate with LibreOffice.

Ah right, well I was about 50% there as I knew LO was C++ but I did think there was some referencing to Java at some point but looking more deeply, I can now see how the namespaces and LO Basic parses them to get to the required methods/function…(I think!!).

And just as I thought somethings were starting to make sense, I found myself in the clouds again as looking at one of the example links you kindly gave me ( createUnoListener and trying to get some understanding of what is referenced and why, I noticed that there are several include statements at the top of the script (and others) ie as an example.

#include <com/sun/star/sheet/XSheetCellCursor.hpp>

but that actual .hpp file cannot be found either by reference of the link itself or in the source code package and the same goes for some other .hpp files.

I can see the related.idl files and are they the replacements for the .hpp files and if so where does the transfer/lookup take place?

Sorry for going on but for me to understand something, I have to go to its roots then work forward otherwise I am looking and something not really understanding its true nature. :smile:

Many thanks
P.R

#10

Yes, for the UNO, we have IDL files (interface definition language), and an own tool that processes the IDL into the generated headers - so all those headers will only appear in your build directory (or pre-built in the SDK package).

#11

Right, I see, so I guess that takes place first before anything else in order to get the generated .hpp in place otherwise the compiler is going to complain…alot!!!
Ok, I think I have a lot of unravelling to do and just as many rabbit holes to crawl through. :laughing:

And talking of compiling, where is the main entry point to start as I can see several?

As I will in time, hope to compile this in VS 2019.
Thanks
P.R

#12

I don’t understand your question. Main entry point into compiling? main entry point of an executable? (then which - we have more than one.) Mentioning some of those several that you see could avoid ambiguity.

#13

:laughing: As I said, its been a while, so please bear with me.

If I create a C++ Win Application (I know this comparing a Flea to an Elephant ), there is an entry point in the script called WINAPI WinMain I think normally.

I can see the file \include\sal\main.h with such an entry but I am not sure if that is the main point of entry for compiling?

I think what I am getting at is, on compiling where does the compiler start first as it can be defined in the properties or at least in VS.

Not sure if that makes any sense…

Thanks
P.R

#14

If I was to debug and put a breakpoint at that line, would that be the first line to be (tried) to be executed or is there another point somewhere else that I need to put a breakpoint on, just to see where it starts.

#15

The entry point of soffice.bin is in desktop/source/app/main.c (indeed, using the SAL_IMPLEMENT_MAIN macro defined in the header you located). It is also used in many other places; and the other one (SAL_IMPLEMENT_MAIN_WITH_ARGS) is used in other places, so there are several executable entry points (each for different executable).

But the soffice.bin entry point have little significance in this project; its main work is done in tens of DLLs. Additionally, the entry point of the executable is not necessarily “where does the compiler start first” - it may appear in any compilation unit, and just needs to appear at linkage point.

If you put a breakpoint there, it indeed would break there; but anyway, you need to realize, that such an entry point is not the actual code that runs first - some runtime library initialization precedes it … and from there, you would have to step hundreds of thousands steps to really interesting code, so don’t put breakpoint there - rather, find a more interesting place.

#16

Ah, now I see, slowly the pennies are dropping.

Ok, I can see this may take a while to figure out and understand before I am going to be comfortable with doing anything with LO internally.

Thank you so much for your time, help and knowledge. :smile:

P.R

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.