> We've reproduced, and therefore fixed, the bug. You'll find the fix in next release. Thank you for your patience.
Sounds good. For other users out there, the workaround is to "unset" the conref first (F2 z). >> 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. Actually, I'm having a hard time reproducing it now too ;-). If I do, I'll try and be more specific on the exact conditions. > You are 100% right. We'll change this in next release. Thanks. By the way, when do you anticipate the next release being available? And what are the major features you're planning? Have you given any more thought to supporting the format="ditamap" method of topicref transclusion (sub-maps)? -----Original Message----- From: Hussein Shafie [mailto:[email protected]] Sent: Wednesday, August 16, 2006 1:41 AM To: Mark Fletcher Cc: xmleditor-support at xmlmind.com Subject: Re: [XXE] dita.setConref changes not being persisted, and bad relative paths generated 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.

