Programmatically inserting a Document using the following code works in 184.108.40.206, but not in 220.127.116.11.
This code is Java & UNO:
XDocumentInsertable xDocumentInsertable = (XDocumentInsertable) UnoRuntime
PropertyValue insertProps = new PropertyValue;
The operation is not throwing an exception, just not inserting the sub-document.
I'm not able to reproduce with 18.104.22.168 & master under Fedora 20.
What's the format of the file you're trying to insert, and what's the extension of that file? Is it possible to attach a sample file that not working? (I'm asking because 22.214.171.124 has a known bug that may prevent this from working properly, in case a file has a wrong extension.)
Thanks for checking. I get the problem trying to insert ODT into ODT or DOC into DOC (the extensions are lower case to match). For example main.odt and sub.odt or main.doc and sub.doc all behave the same - the insert doesn't seem to do anything.
I created a new pair of ODT files to be sure the file name and file format were definitely ODT. Same problem.
If I do it manually no problem with these files it works. The same code and files work ok using UNO and Libre Office 126.96.36.199.
I will attach two files (main.odt and sub.odt). I can try creating a cut-down test - but there's a fair bit of code.
Created attachment 104832 [details]
main ODT document
Created attachment 104833 [details]
second document (to insert into the first)
Created attachment 104835 [details]
(In reply to comment #2)
> I can try creating a cut-down test - but there's a fair bit of code.
That would be great, because I can't reproduce it locally. Attached my working code.
Thanks very much for the simple sample - that helped me diagnose the problem very quickly and then relate back to my code to find out what was wrong.
Your initial comment was spot-on - it was the file-extension of the inserted document. My code was creating a temp file with no extension and that file won't insert unless an extension is added.
Could you please point me to that bug? This issue should be closed now.
Thank you again.
*** This bug has been marked as a duplicate of bug 81113 ***