[Libreoffice] [PUSHED] How to create get an XWorksheet from a XSpreadsheet?

[Markus Mohrhard]

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 at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110417/869e5c0e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fixed-problem-with-return-value-in-ScVbaWorksheet-cr.patch
Type: application/octet-stream
Size: 14062 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110417/869e5c0e/attachment-0001.obj>