> 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.




Reply via email to