Created attachment 184570 [details] This IDL definition fails JAVAMAKER after running IDLC and REGMERGE successfully. I've developed two succesful Calc extensions, both written in Java using the old method of hand-coding everything. However a current project using 'javamaker' fails when that utility diagnoses: ERROR: Unknown entity 'com.sun.star.uno.XComponentContext' Both 'idlc' and 'regmerge' run successfully. Similar behaviour is reported on github also at https://flywire.github.io/lo-p/47-Calc_Add-ins.html - see Chapter 47, section 2.4. "Problems with Office Types". QUOTE: "Office's idlc.exe and regmerge.exe tools are happy to process these types, but javamaker.exe always fails to recognize 'com.sun.star.table.XCellRange' and 'com.sun.star.sheet.XVolatileResult', reporting an "Unknown entity" error. I tried calling javamaker with the inclusion of extra Office RDB files, such as services.rdb and offapi.rdb, but with no success. I was unable to find an add-in example online that uses XCellRange, perhaps because it's more natural to pass a cell range to a function as an array. UNQUOTE Attempting to run idlc / regmerge / javamaker on an earlier hand-coded extension which has run successfully over several versions of LibreOffice results in exactly the same problem. Since this earlier extension works, is simpler, and shows the same problem it's copied here as an example. Note, the directive to "include" <com.sun.star.uno.XComponentContext.idl> was inserted to see if it fixed the problem, but isn't in the original IDL definition. Regards!
Stephan: thought you might be interested in this one since it concerns IDL, Java.
You're presumably missing a reference to the URE types.rdb when invoking javamaker: In a LO 7.3 SDK environment on Linux, with your attachment 184570 [details] as test.idl, > $ idlc -I"$OO_SDK_HOME/idl" test.idl > $ regmerge test.rdb /UCR test.urd > $ javamaker -X"$OFFICE_PROGRAM_PATH/types.rdb" test.rdb successfully generates org/openoffice/adl/util/CalcDL1.class and org/openoffice/adl/util/XCalcDL1.class.
(In reply to David Lochrin from comment #0) > Similar behaviour is reported on github also at > https://flywire.github.io/lo-p/47-Calc_Add-ins.html - see Chapter 47, > section 2.4. "Problems with Office Types". (I reported <https://github.com/flywire/lo-p/issues/13> "Fix for 'Chapter 47. Calc Add-ins: 2.4. Problems with Office Types'" there now.)
Many thanks, Stephan and Julien, for your help, that did indeed solve the problem. There's no doubt the LO API is a great thing as it allows a user to leverage the power of Calc by many orders, especially when Calc cell formulae become so complex their further development begins to be impracticable. (I'm doing some amateur Covid epidemiology.) However the API documentation is not very coherently presented IMO; for example, the intention behind the three versions of the 'setsdkenv*' utility only becomes clearer when the scripts are directly compared.