Apache OpenOffice (AOO) Bugzilla – Issue 19100
DDE link leads to wrong path
Last modified: 2017-05-20 10:48:12 UTC
I checked with 1.1RC3 German version WIN98SE: 645m15(Build8669) [CWS:ooo11rc3] and also 645m17 8683 I see a bug which can be reproduced with attached example documents. test0.sxc only contains 2 dde-links to cells in "testfile1.sxc" and "testfile2.sxc" in subfolders. The dde-links are _relative_, so that the testfiles can be installed anywhere on your PC Steps to reproduce: 0. unzip "test0.zip". You will get a file "test0.sxc" and 2 folders "test1", "test2" Might be that it will be helpful to install that not directly to the root directory, but to something like C:\...\...\...\...\yournewtestfolder\test0.sxc C:\...\...\...\...\yournewtestfolder\test1\testfile1.sxc C:\...\...\...\...\yournewtestfolder\test1\test2\testfile2.sxc 1. goto C:\...\...\...\...\yournewtestfolder\ and open test0.sxc by doubleclick expected: dde-links will fetch text for cells A1 and A2 from other files. actual: contents for A1 will be fetched, but fetch for A2 fails with error message. I tried 10 times and the problem was 100% reproducible for me. The problem is caused by an incorrect absolute link, which is created by OOo. To fetch the contents for A2, a dde-link is required to C:\...\...\...\...\yournewtestfolder\test1\test2\testfile2.sxc but actually (look to the error message) the link leads to C:\...\...\...\...\yournewtestfolder\test1\test1\test2\testfile2.sxc This problem only happens, if both links are used more or less in time, an update with menu "edit-link" never fails. We have a similar problem in another issue 17124, might have the same reason? Rainer
Created attachment 9022 [details] Testfiles (some in subfolders)
Calc is not my turf ;-)
Sorry, but this definitely is not a "spreadsheet - issue". You can find the same problem with DDE- links in the WORD PROCESSOR. Please see attached testfile "texttest", you can make a test like listed in my first report. So I rechange component to UI until someone finds a better solution. I tested the problem with the sxw- files and saw: - No problem if I use _absolute_ DDE- links - Problem as reported after I changed to _relative_ DDE- links Rainer
Created attachment 9028 [details] Same test with .sxw writer document
It's not a UI issue either - not everything that is visible is automatically a UI issue ;-) Which component's issue it is is to be determined. Could you give a step-by-step explanation how you created the links?
Hi Oliver, I agree, but for me UI seems to be the best "do not really know what else" component ;-) It does not matter to the effect how you create the DDE- Links. In all attached files I did it so: 11. Mark source field in sourde fild 12. Cntrl-C 13. go to File where DDE link is to be inserted 14. Paste Special "DDE" 15. Same for second DDE- link 16. goto file where DDE- links are inserted 17. menu: Edit-Links-Modify 18. Delete "absoluet part" of the link. so that only "subfolders\file.sxc" will remain You might get an error message (... not available ...), but that does not matter, the link will work. Rainer
I've found the right component. The problem is in svx\source\svxlink\linkmgr.cxx lcl_DDE_RelToAbs() The relative URL of the link is made absolute using the damned base URL. The base URL is static and changed once a document is loaded. In this case the first loaded sub document changes the base URL. The second relative URL is now made absolute using this URL :-( A sensible solution is to use the referer URL (the one of the container document of the links) to convert relative to absolute URLs when it's available.
.
Hi Oliver, that's good news! Can you have a look to issue 17124? Might be that problem is related to this one. Rainer
Deleted fst from CC.
Issue 17124 might be caused by a similar problem but it's definitely not at the same location.
os->mba: Do you see a problem in exchanging the BaseURL with the Referer's URL (if available) in lcl_DDE_RelToAbs ?
That's a reasonable approach. I changed the code in the suggested way.
Can you estimate in wich stable version this fix will be included? Rainer
If "stable" means "stable" ;-) of course it will be the OOo2.0 version. You can find the proposed release dates for the Beta and Final on our Website. If you wanted to know in which developer build you can get this fix: my estimation is that it will be available around end of July. I could arrange to get the fix 2-3 weeks earlier, but that's not for sure.
Either the suggested fix didn't work or the feature broke again: it seems that the attached document doesn't work in the last milestones. I will investigate this later.
The reason for the bug now is that the call ::ucb::getFileURLFromSystemPath( xManager, rBaseURL, rName ); forwards to the file UCP and the file UCP ignores rBaseURL. I assume that this method should accept relative system pathes, makes them absolute and returns the absolute file URL, but the file UCP doesn't. I added Kai in case he has some useful information I couldn't find in the ucbhelper header and the IDL documentation for the XFileIdentifierConverter interface.
ABI->HRO: getAbsoluteFileURL should implement RFC-conform handling of BaseURL, as discussed. Please use cws abi14 to implement. There is a bug fix in ucb/source/ucp/file/prov.cxx also, which is needed to make a complete fix.
REmoved myself from CC list.
Currently 2.0 (1.9.m125) German version WIN XP: [680m125(Build8947)] seems to accept only absolute DDE links. I would not be very happy with such soulution.
ABI: reopened, because the bug is now in the product again: extremly slow startup performance under win98/Me, because a system function is badly implemented and the function is called very often. re-open issue and reassign to abi@openoffice.org
reassign to abi@openoffice.org
reset resolution to FIXED
reopened, due to windows 98/ME performance re-open issue and reassign to abi@openoffice.org
Reopened: Needs optimized implementation of getFileURLFromSystemPath in osl. re-open issue and reassign to abi@openoffice.org
reopened
ABI->HRO: The bug cannot be fixed without optimized version of getFileURLFromSystemPath in osl for windows98. Please provide this function. The ucb - code is already in CVS.
*** Issue 37464 has been marked as a duplicate of this issue. ***
Sorry, no time to fix this in 2.x time frame.
mav: Please take over. Win98 only? Not quite sure.
As I can see in description, the bug was fixed and the only issue is the performance on Win98 platform. Since Win98 is no more supported, there should be no more reason to leave the bug open. mav->rainerbielefeld: Can you still reproduce the original problem in OOo3.1?
I did a new test with "test0.zip" / "1.1.4 (German) WIN XP: [645m52 (Build 8824)]" Does not work, Error message "file ..... does not exist". Manual link update works fine. "texttest.zip" / "1.1.4 (German) WIN XP: [645m52 (Build 8824)]" Does not work, Error message "file ..... does not exist". Manual link update works fine. "test0.zip" / "2.0.2 German version WIN XP: [680m5(Build9011)]" does not work, no linked contents, no error message, manual update impossible "texttest.zip" / "2.0.2 German version WIN XP: [680m5(Build9011)]" does not work, no linked contents, no error message, manual update impossible "test0.zip" / "Ooo 3.1.0 WIN XP multilingual version German UI activated [OOO310m11 (Build 9399)]" does not work, no linked contents, no error message, manual update impossible "texttest.zip" / "Ooo 3.1.0 WIN XP multilingual version German UI activated [OOO310m11 (Build 9399)]" Old time and date (2003) shown as contents, no error message, manual update impossible Conclusion: Nothing works with 3.1.0 That's even much worse than when I reported this bug, but what are 5 years for an "OOo Later" bug ;-)
Thank you for the detailed testing. Changing the target to OOo3.x for now.
Reset assigne to the default "issues@openoffice.apache.org".