https://bugs.documentfoundation.org/show_bug.cgi?id=142635
Mike Kaganski <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #16 from Mike Kaganski <[email protected]> --- The problem happens in lcl_ScAddress_Parse_OOo (sc/source/core/tool/address.cxx) during *copy* to clipboard. The 'if (!bExtDoc && !rDoc.GetTable( aTab, nTab ))' branch executes (because rDoc doesn't happen to have the table (sheet) with the "Sheet.1" name), and then for the testcase from comment 0, the 'if (n > 0 && aTab.getLength() - n <= 4)' executes, as if ".1" was a file extension, making the import code think that it was an external reference (for names without a dot, or with more than 4 characters after the dot, it would be different - likely manifesting as comment 15 describes). The copy code has at least three ScDocument live on the call stack: the original document, the clipboard document, and some temporary document used in Chart-specific code here; the latter has no correct table name (yet?). I suppose that the range a2e6f31c6f90e446d1462e7c80f6b1317f7825bc .. b9652803096b68a33702601aac52e78c8a4250c6 could change something that the platform-specific clipboard code now could do something with the Chart-specific ScDocument so that it already has correct table names when this code executes, while Windows-specific code does that in a different order. However, the multiple "works here on Windows" responses look confusing, given how consistently reproduce the problem on Windows on my system (and the test failing for me locally - that I disabled in the commit mentioned in comment 2 - at least worked fine on Jenkins Windows builders). Eike: do you have an idea where could I look at to find the problem? -- You are receiving this mail because: You are the assignee for the bug.
