[libreoffice-dev] - building difficulties with C++ extension,addIn

Wed Jan 9 08:31:55 PST 2013

Hi Stephan,

Thanks for taking this up. I wasn't aware that examples didn't get built with make or make check.
Time is not a big issue as long as it gets to the right place, and it seems like you are pushing it in right direction.
I noticed that you are listed UNO,sal,config contact. Hope it is ok if I address future issues to you. I'll try to limit my spam to once a day.

After my last email, I noticed some issues with the cxx file I attached. attaching an updated version. Also Makefile uses more standard env vars.

This is not a complete Calc add and I'm still working to incorporate other functionality from Scalc.java.
But as a standalone calc extension took me 8 days, I thought this might be worth sharing already.
If I am ready with the richer functionality by the time right place is decided, I'll share that too.

I think myRNG.tar is also very good example, as it works out of the box, as long as sdk is installed and env is set.
The extension docs looked overwhelming when Michael 1st mentioned it, but thanks to myRNG examples, I was able to get past that.
Hope that also finds a place in your new scheme of things.

Not sure if this is related to any restructuring you guys are planning, but as of this moment, the wiki I used is down.
http://wiki.openoffice.org
This may be legacy and the info may belong elsewhere, or maybe Oracle owns it and finally decided to take openoffice closed source:-)

Thanks
Neeraj

-----Original Message-----
From: Stephan Bergmann [mailto:sbergman at redhat.com]
Sent: Wednesday, January 09, 2013 5:28 AM
To: 'libreoffice at lists.freedesktop.org'
Cc: Rai, Neeraj [ICG-MKTS]
Subject: Re: [libreoffice-dev] - building difficulties with C++ extension,addIn

Hi Neeraj,

Thank you for taking the trouble of making your Calc addin example work.
  The SDK is indeed an area that could benefit from more maintenance
help, lots of the documentation goes stale over time etc.

That said, I'm not sure we'll improve the overall situation by adding
more examples directly to the SDK.  The content of the SDK is backed by
module odk in the core LO git repo, so the example code ends up in the
core repo, where greps and wholesale code-cleaning activities (like some
EasyHacks) stumble upon it, modify it, etc.  But due to the awkward way
the SDK needs to be set up for use (another area that would benefit from
additional help), those examples do not routinely get tested (e.g., are
not compiled and run during a build, not even a "make check" one).

Therefore, I wonder whether it would not make more sense to have some
place of its own for such additional examples to reside in, like in a
wiki or some repository similar to LO's extensions and templates sites.
  I'll see to get that issue addressed and come back here.

Thanks again for your work and for your patience,
Stephan

On 01/08/2013 08:45 PM, Rai, Neeraj wrote:
> Hi Michael,
>
> I was able to work around the problem below by removing the platform tag.
> For now, I am happy with legacy active registration.
> I now have a working example of Calc extension in C++ (on lines of example/java/SpreadSheet/CalcAddins)
> Thanks for your help.
>
>
> I noticed that you are listed as one of the developers for soffice. Would you be able to take this code and introduce it as part of package ?
> Same might be done for myRNG.tar.gz.
> I think calc is an important part of soffice and having a c++ extension readily available would attract more users to it.
> It took me days to get this working, but for anyone henceforth it should be 15 min.
>
> Unfortunately, I am behind firewall and can't access gerrit. I am attaching the file with this email.
> If there is a better way to get it as part of installation, I'll be happy to contribute.
>
> Thanks
> Neeraj
> -----Original Message-----
> From: Rai, Neeraj [ICG-MKTS]
> Sent: Monday, January 07, 2013 7:30 PM
> To: Michael Stahl
> Cc: 'libreoffice at lists.freedesktop.org'
> Subject: [libreoffice-dev] - building difficulties with C++ extension,addIn
>
> Hi Michael,
>
> I tried your extension suggestion to convert examples/java/SpreadSheet/CalcAddins.java to C++.
> I am having problem installing my extension using unpkg.
> Error : The extension "my simple extension" does not work on this computer.
> I tried various values in META-INF/manifest.xml : platform=linux_x86_64 and platform=all but I get the same error.
>
> I probably did something wrong transporting the xml files or oxt files from the example.
> The original example in java works for me.
> Would you happen to have expertise in this area and time to help me out ?
>
> I also came across the following link which states that regmerge is legacy. However, the CalcAddIn was using it, so I went with it too.
> http://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Deployment_Options_for_Components
> If that is the not the right way forward, please point me in the right direction.
>
> Thanks
> Neeraj
>
> -----Original Message-----
> From: Michael Stahl [mailto:mstahl at redhat.com]
> Sent: Thursday, January 03, 2013 3:44 PM
> To: Rai, Neeraj [ICG-MKTS]
> Cc: 'libreoffice at lists.freedesktop.org'
> Subject: Re: [libreoffice-dev] - architecture question about interproces,extension,addIn
>
> hi Neeraj,
>
> On 03/01/13 16:54, Rai, Neeraj wrote:
>
>> Based on above text, I looked at addIns but it doesn't seem like what I
>> need.  I don't want to be restricted to a function call. I need a
>> component running in scalc.
>>
>> _http://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Spreadsheet_Add-Ins_
>>
>> Can someone please advise what is the "fastest code as a C++ UNO
>> component " mean and where can I find more docs related to it.
>
> C++ UNO components that are instantiated in-process currently do not go
> through a bridge when interacting with the LO API (although there have
> been varying opinions about changing that, since it makes maintaining
> backward compatibility more difficult): for such components, calling a
> LO API method (or being called from LO itself) is just a C++ virtual
> function call.
>
> the best documented way to get this performance benefit is to implement
> your client code as an extension.
>
> http://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Extensions
>
> there may also be a way to get there with less efforts, there are some
> variables to add additional service rdbs to the soffice process
> (URE_MORE_SERVICES/URE_MORE_TYPES) but i don't have any experience with
> them; probably there is some way to implement what you want to do as a
> service and then start it from inside soffice, if all else fails via a
> trivial BASIC macro :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CalcAddinCpp_impl.cxx
Type: application/octet-stream
Size: 19233 bytes
Desc: CalcAddinCpp_impl.cxx
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130109/5a07bdb1/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 1784 bytes
Desc: Makefile
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130109/5a07bdb1/attachment-0003.obj>