I have a spreadsheet created in Openoffice 3.2 which has links to and from a Control sheet to other sheets in the same document. This works fine on Openoffice, but not in Libreoffice. When I click on a link on the control sheet, I simply get moved to a cell a lot further down and across.
Created attachment 41976 [details] Sample file for demonstration
@reporter: Please contribute information concerning your OS, LibO Version, Platform, ...
I'm using Windows XP and Lireoffice release candidate 2 (&3) (In reply to comment #2) > @reporter: > Please contribute information concerning your OS, LibO Version, Platform, ...
Reproduced on RC3, Ubuntu 10.04, x86. Moved to cell JW131210, not to list with this name.
Got it! - the sheet names resemble cell references. Just need to rename sheets with a slightly different system. Many thanks for all your help. On 15 January 2011 15:01, <bugzilla-daemon@freedesktop.org> wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=33067 > > --- Comment #4 from tester8 <iamtester8@gmail.com> 2011-01-15 07:01:08 PST > --- > Reproduced on RC3, Ubuntu 10.04, x86. > Moved to cell JW131210, not to list with this name. > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
Hmm, so you mean there wasn't any bug after all?
(In reply to comment #6) > Hmm, so you mean there wasn't any bug after all? Technically, the bug exists, but it's merely a coincidence with the way I was naming my worksheets. I was naming the sheets with a subject's initials and the date the sheet was created (e.g. a sheet created for John Smith today would be JS180111). Libreoffice reads this as a cell reference rather than as a sheet reference. It worked fine in Openoffice 3.2, but not in Libreoffice RC 2 or 3. So, yes, the bug exists, but it's not life threatening.
Can simply be reproduced Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 81607ad-3dca5fd-da627d2)]": 1. Open new CALC document and save it as Testdocument.ods 2. Rename Sheet 2 to "BT311210" 3. Sheet1 A1: type xxx 4. <Control+a> to select a 5. Toolbar icon Hyperlink Hyperlink dialog opens 6. Click 'Document' Document related info appears in dialog 7. Click 'Target in Cocument' 8. Select 'Sheets' 9. Select sheet "BT311210" 11. <Apply> then <Close> 12. <Apply> then <Close> Now you have Text "xxx" with hyperlink in A1 14 Click hyperlink Expected: Jumps to Sheet "BT311210" Actual: Jumps to Cell "BT311210" on Sheet 1 To be honest, I never thought about necessity to distinguish between links to cells and links to sheets, to be honest, I even did not know that it is possible to create a link to a Cell. But When I created a link to a Sheet using dialogs, the result should be the expected link and nothing else. OOo Heritage, same issue with OOo 3.1.1 New / confirmed due to my results and tester8's confirmation @kevinsjunk: A Bug remains a bug also if it's no longer a problem for you @David: Would be interesting to know what the ODF definition says - you can help? BTW, I would really like to know wht "impex" on <http://wiki.documentfoundation.org/FindTheExpert> might mean
Kohei: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Unfortunately we can't distinguish a name like that. If a name can be resolved into a valid cell address, that one takes precedence. We have the same limitation between cell address and range names as well. So, we just need to be aware of this limitation, unfortunately.
@David Nelson: I do not know whether such limitations are mentioned in Help or Manuals, in Help I only found limitations if the document will be saved as .xls. May be some hints: "Hyperlink target names can not be be distinguished for cell references, named ranges, sheets and ..., so seek to reach distinctiveness. LibOs priority to appoint the target is ..., ..., ..." would be useful? I do not know whether other LibO applications have similar limitations, I remember problems with numbered headings in WRITER, but I am not sure whether that problem still exists.
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.