Re: [Libreoffice] problem with ScTableSheetsObj::replaceByName

Hello Eike,

> > while writing api tests I found ScTableSheetsObj::replaceByName. The
> > method should take a name of a sheet and a ScTableSheetObj wrapped
> > into an uno::Any and then replace the old sheet with the new one.
> >
> > I identified now several problems in this method. Line 2568 tests that
> > the ScTableSheetObj does not yet have a ScDocShell which means it is
> > not yet part of a ScDocument. But as much as I know of calc's design
> > we can not have a ScTableSheetObj (the uno implementation for a single
> > sheet) without it being part of a ScDocument. Normally you don't have
> > access to a ScTable except through a ScDocument and a ScDocument has
> > either a ScDocShell or should be an undo or copy document.
>
> It seems (didn't check for the specific service name, there ought to be
> some table somewhere) one can create a sheet instance via
> ScModelObj::createInstance() that doesn't have a ScDocShell, at least
> there's a comment in ScCellRangesBase ctors of which ScTableSheetObj is
> derived that mentions createInstance. In fact all ScCellRangesBase
> methods check for pDocShell.
>
> > If this part of my analysis is correct there is right now no way to
> > use this method without getting an exception. But even if we would be
> > able to create a ScTableSheetObj that is not part of a
> > ScDocument/ScDocShell we would be running in the problem that the
> > method would not do more than deleting the old sheet and inserting a
> > new empty sheet with the same name.
>
> Well, yes, that seems to be the outcome ;)
>
> > If all parts of this are correct I suggest that we implement more
> > something like: delete sheet and then create a copy of the passed
> > sheet at this place with the new name.
>
> Um.. how would you create the copy?

Through ScDocShell::TransferTab with bInsertNew = true. That is the
same as a copy in the dialog. The only arguments against this idea is
that we do exactly this in ScTableSheetsObj::importSheet already.

Any better ideas for that?

Markus