Mark Fletcher wrote: >>I'm sorry but I cannot reproduce this problem, at least when I use > dita.setConref normally. > > Hmm. I've double-checked and I can reproduce with the out-of-the-box > addon. Again, my steps to reproduce were: > > 1. Open a file with an existing conref. > 2. Select the conref source element and press F2 Shift+V > 3. Use the file chooser dialog to choose a different target file. > 4. Click OK. (The new content is transcluded.) > 5. Save and close the file. > 6. Reopen the file. (The old content appears because the original conref > path is still there.)
We've reproduced, and therefore fixed, the bug. You'll find the fix in next release. Thank you for your patience. >>When you use dita.setConref, please always pass it an *URL* (absolute > or > relative) and never a filename. If you use [clipboard], the clipboard > must contain an URL (absolute or relative) and never a filename. > > The file path examples (c:\xxx\xxx.xml) I gave are not what I'm entering > manually into the dialog; they're just for illustration of the relative > file locations. I'm using your file chooser dialog to point to my conref > targets. I've retested this on Windows: --- source file is c:\private\file_1.xml I use dita.setConref and map a conref to c:\user_doc\topics\file_2.xml The resulting conref url looks like this: ../../c:/user_doc/topics/file_2.xml --- When XXE is used normally: no filenames/URLs typed by hand, I didn't manage to reproduce the problem. My guess is that the problem is related to the fact that filenames are case-insensitive on Windows, while URLs are case-sensitive. Here's what happens (I think): --- source file is file:/c:/private/file_1.xml (this happens if, for example, you open a file from the command line: "xxe.exe c:\private\file_1.xml") I use dita.setConref and map a conref to file:/C:/user_doc/topics/file_2.xml (chosen using the dita.setConref dialog) The resulting conref url looks like this: ../../C:/user_doc/topics/file_2.xml --- We'll *try* to fix this problem but I cannot give you my word that we'll succeed. >>I understand but the rationale is: you have already chosen a conref > *target* in this directory, therefore there are chances that you choose > the new conref target from the same directory. > > I think it's great that you can choose another conref target from the > same directory (ie, the file chooser remembers your last location). I > just think the Set conref dialog should display the path in relation to > the conref source, not in relation to the last target. > You are 100% right. We'll change this in next release.

