https://bugs.freedesktop.org/show_bug.cgi?id=81435
Albrecht Müller <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=81291, | |https://bugs.freedesktop.or | |g/show_bug.cgi?id=81293, | |https://bugs.freedesktop.or | |g/show_bug.cgi?id=43003, | |https://bugs.freedesktop.or | |g/show_bug.cgi?id=74014 See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=74756 --- Comment #5 from Albrecht Müller <[email protected]> --- @Joel I think ign_christian already provided the information you needed. I had no way to check if this ever worked as I have only one installation of Libre Office and my bug reports resulted from my first trial to combine the contents of two spreadsheets. To put these problems in context here is the story of the user experience: I have a couple of spreadsheets containing diagrams together with the corresponding data. They are essentially modified copies of a common ancestor, thus containing roughly the same set of names. The purpose of using names is to avoid mistakes when adapting the copies to different data. I wanted to sum up the contents of two of these spreadsheets. I ruled out the option to create an additional spreadsheet for the following two reasons: a) I fear that Calc can only use absolute references to other files. Therefore moving or renaming the containing directory would break references to the other spreadsheets. b) I wanted to reduce the number of files. Therefore I wanted to create a copy of one file, add the sheets contained in the other file, create an additional summary sheet and delete the original files. I thought this would be a quite common task and therefore did not prepare the files for the merge assuming that a reasonable spreadsheet program would detect the problems related to this operation and do something useful about it. Obviously there are name collisions which could be resolved for example by renaming. There are also ambiguities when names are copied: Should they point to the original file or to the correspondig location in the targed spreadsheet? What should happen, when the specified range does not (yet - assuming you copy the sheets one by one) exist? So I went ahead and what followed was a nightmare. When things did not run as smoothly as expected the first idea was to look at the names: Select a cell in order to see its formula in the input line, press CTRL+F3 to get the names dialog, arrange dialog size and colums so to be able to see the relevant information. Now a look at the input line to check it against the names dialog: Uups - the content of the input line is gone (see bug 81291). Close the dialog and the input line is there again, but now I was not able to see the name information. Trying to remember the necessary information and opening the names dialog again. Now I have to rearrange the contents of the name dialog again, otherwise I cannot see what I want to check. Done - oh, now I an not sure if I remembered correctly what I wanted to check ... I think you get the picture - gives bug 81293. After having developed strategies to cope with this behaviour, it took me hours of experimenting until I was able to distinguish between some of the strange effects I observed and to create a few examples demonstrating them: A data loss, where actually no data were lost - bug 81294, fixed already. I could create an example that - in my opinion - demonstrated that something was wrong with name scope handling (bug 81295) as switching the scope of a name and changing it back to the same value as before resulted in permanent changes in the contents of the spreadsheet. In the meantime I learned that what I considered a data loss seems to be the intended default behaviour. No problem, as everybody (now including me too) knows that there is a switch that allows you to change this behaviour. Due to my ignorance of this fact the idea to repeat the name used for a cell range as a header for that range caused me quite a few headaches. And there is the situation where all things look good, but it is just because you do not notice the loss of data immedately - which is bug 81435 (this one). In my opinion this kind of error is especially nasty as you may detect the problem only a long time after the actual loss of data and therefore you cannot tell when and why it happened. This ruins the trust in the program. I also encountered some errors that are already known for quite some time (e.g. bug 43003, bug 67581, bug 74014, bug 74756 and bug 81330), and additional problems I did not investigate further or create bug reports for, e.g. how do I make sure that my spreadsheed does not contain references to others spreadsheets? How do I find the cells containing the external references (including those contained in diagrams)? All these these things occured while I tried to achieve what I think is a common and basic task - summing up the contents of two spreadsheets. And that's only Calc, there is Writer loosing references to headlines and Base truncating MS Access Memo Fields to about 255 bytes ... (No bug reports created for these, too much work to find out the exact situations that reproduce these problems). Libre Office may be quite expensive for companies that have to pay for working time. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
