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 thinkP.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 conversionhmm 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