[Libreoffice] [Patch] allow one anonymous db range per sheet in calc

Markus Mohrhard markus.mohrhard at googlemail.com
Thu Mar 24 09:43:54 PDT 2011


Hello,

so there is the next try. I've just followed Koheis' suggestions and made
the anonymous db a part of ScTable.

Patch is of course under LGPLv3+/MPL.

Markus

P.S. Sry that patch is not created with git format-patch but I don't know
how to create a patch against a specific point

2011/3/22 Kohei Yoshida <kyoshida at novell.com>

> On Tue, 2011-03-22 at 19:59 +0100, Markus Mohrhard wrote:
> > This time with the patch. Sry.
> >
> > 2011/3/22 Markus Mohrhard <markus.mohrhard at googlemail.com>
> >         Hello,
> >
> >
> >
> >         so I have reworked it. I haven't reworked the import and
> >         export as these affect some areas I don't fully understand.
>
> Hi Markus,
>
> So, I've tested your patch, and it works as long as the sheets are not
> moved around, but once you start moving sheets around it starts to act a
> bit weird.
>
> Here is an example.  Let's say you start with an empty document.  You
> put some data into Sheet1, and set autofilter there.  Now, move Sheet1
> to the right of Sheet3 so that the sheets are in this order (from left
> to right): Sheet2, Sheet3 and Sheet1.  Now, put some data into Sheet2
> and set autofilter.  The autofilter on Sheet1 now vanishes.
>
> This was what I was concerned about earlier.  Because we are using the
> sheet index as part of the name, and use it to look up the sheet-local
> anonymous DB data in ScDocShell::GetDBData(), it becomes susceptible to
> sheet relocation.  Note that sheet index (nTab in ScTable) is always
> numbered 0, 1, 2, from left to right.  So when you move a sheet, Calc
> updates its index to reflect its new position.
>
> Thinking about this a bit, I think the best solution is *not* to store
> the sheet-local anonymous DB's in the global ScDBCollection instace, but
> store them directly in the respective ScTable instance, and adjust the
> lookup code accordingly.  I think this is a much better solution given
> the constraint, and one that I would feel more comfortable with.  Sorry
> I didn't think of this sooner.... :-/
>
> Regarding the import export, let's not worry about that at this stage.
> We should first focus on getting the core functionality working first,
> before worrying about file import / export.
>
> Regards,
>
> Kohei
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110324/b5295a46/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anonymous db range.patch
Type: application/octet-stream
Size: 26110 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110324/b5295a46/attachment-0001.obj>


More information about the LibreOffice mailing list