GNOME Bugzilla – Bug 706671
Internal links are stored as strings rather than expressions
Last modified: 2017-03-06 01:29:40 UTC
Created attachment 252879 [details] an attempt to modify an existing internal link. Gnumeric 1.12.4 Ubuntu Linux 13.04 Fluxbox/Rox In a worksheet of several tables, I decided to split-up one table on several dedicated tables. As some links point at the original table, I have to adapt them in the source-tables. Doing so by pointing with the mouse on the new target range, produces invalid range references, like TableName!A4:A5!A5:A6. See Screen-shot. In the screen-shot, please ignore all those bizarre tooltips. They are subject to another bug-report (https://bugzilla.gnome.org/show_bug.cgi?id=706659). As a consequence, all links must anyway be modified manually. Cheerio.
I cannot replicate this. Would you please describe step by step what you are doing?
Created attachment 252948 [details] Evolving database of my vegetable-seeds. This version of the file contains the tables 'semer', 'repiquer' and 'recolter' which replaced one table 'saisons'.
Okay, I see there is a critical point in the procedure. The phenomenon can be observed only, when you rename (or remove) the table that has originally been the target of workbook-internal links. What I did was the following: 1. rename a table «saisons» to «semer» This enders all links pointing to ranges in 'saisons' invalid. 2. create two new tables «repiquer» and «récolter» 3. went to another table, where I modified all existing links to 'saisons'. Middle-click on a cell, containing a link, select "internal link" (sorry, my Gnumeric speaks German, I do not know what it proposes in the english locale), clicking the button which allows to point at the target range. Voilà. I mean, there! The file is the one, that you know from the other bug but I add as an attachment to this message the current version with the new tables.
Okay, I see. So th eproblem isn't really the behaviour of the expression entry. YOU are starting with an invalid expression and so the entry selects a valid portion of it. The real issue is that as the sheet is renamed the internal links are not correctly adjusted. There should be no need for you to adjust hte link addresses to the new sheet name.
(In reply to comment #4) > There should be no need for you to adjust hte link > addresses to the new sheet name. Thank you for this opinion... or do you think it was meant that way in the beginning.. ? ;-> never mind.
I really can't imagine that anybody intentionally wanted to keep the name of the internal link address fixed. We don't do that anywhere else in Gnumeric. So I think that is just a bug that wasn't reported (probably because few people use internal links.)
I just hit that while creating test cases.
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.