Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hello Noel,

I have found the reason why setUpDocumentModules won't work correctly with
the new method. It seems that the method will only work when the name and
the code name of a ScTable are the same. I have worked with a document where
this is not the case and then XNamedAccess->getByName(String aName) will
fail for these elements if aName is the Name of the Table but not the
CodeName. So I fixed this problem and moved the method to excelvbahelper.

There was also a little bug in ScVbaWorksheets::Copy. You removed one loop
but the second loop must start with the second element if a new document was
created.
With a document with Sheet1, Sheet2, Sheet3 and the VBA code Sheets.Copy
something like this was produced in the new document:

Sheet1, Sheet1_2, Sheet2, Sheet3

There are still some bugs in ScVbaWorksheet[s]::Copy, but it seems that they
were not introduced with my last patch. References in the copied sheets fail
under some circumstances. I'll have a look at these cases.

Regards,
Markus

2011/4/15 Noel Power <nopower@novell.com>

 Hi Markus

  ok, first using getCurrentExcelDoc is not really recommended ( when we
actually know the target document ) 'active' is a little arbitrary and I am
not sure in this case whether there is a timing issue between the document
being created and being recognised as 'active'. But regardless of that the
getUnoDocModule is not going to succeed as the (new) document is not vba
enabled. Some post processing of the document is needed to ensure that
works, like I said.. if you are interested in hacking on that as a separate
issue then I can give you pointers how that is done ( actually it is already
done in ScVbaWorkbooks ( see setUpDocumentModules method ) ) but that method
would need to be generally available in excelvbahelper I think


 P.S. Even some really strange ways of using the
setUpDocumentModules(const uno::Reference< sheet::XSpreadsheetDocument >) of
vbaworkbooks.cxx produces an error. But this seems a good way to solve the
problem. If you can give me any hints why this won't work I will try again
on the conversion

 hmm not without looking more closely at that ( which I will try to do
later ) it imo should work

now on to the patch :-)

in vbaworksheet.cxx

+    //#TODO #FIXME
+    //return the new XWorksheet
+    return;

I meant to not return NULL but pass NULL as the parent of the Worksheet
;-)  fixed that ( of course we need to look into the problems mentioned
above to see what we can do to get the correct parent )

A few more changes were needed to vbaworksheets, mostly these changes were
required because on testing it became clear that things weren't working
exactly as expected and there are a few bugs e.g.calling
   Worksheets.Copy()
creates a copy of the sheets in a new workbook but there are in reverse
order

Similarly when calling
   Worksheets.Copy before:= Worksheets(2)
the sheets are also copied in reverse order. I fixed those 2 problems and
additionally reworked the method and removed one of the loops in the
ScVbaWorksheets::Copy method

thanks again for this useful patch, look forward to you next contribution

Noel




Attachment: 0001-fixed-problem-with-return-value-in-ScVbaWorksheet-cr.patch
Description: Binary data


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.