Microsoft swipes .xml extension ... again ... this time for good?

[naglists]

Our authors have been losing their .xml file association with Editor. In one
of our applications we had previously deployed the following code in their
Editor startup batch file:

assoc .xml=xmlfile
ftype xmlfile="C:\Program Files\Arbortext\Editor52\bin\epic.exe"
-newinstance

This seemed to have solved the problem the last time a Microsft "fix" stole
the association.

This go-around, adding this code to other applications' batch files has not
always restored the connection.

I have found some references indicating that the order of those commands
should be reversed, but in this instance, it doesn't seem to work as hoped
for in either order. What is now happening, for some (albeit an increasing
number of) authors, is that they open Editor using a shortcut that calls a
batch file. Then they open XML either by double-clicking it on the file
system somewhere OR by selecting EDIT or VIEW in a Documentum Desktop
integration with Windows Explorer OR by selecting EDIT or VIEW in
Arbortext's Documentum Adapter. In the "old days" this would hand the XML
file to the existing Editor session. What is happening now is that the
existing Editor instance/sessions is brought to the foreground BUT no file
opens. Code in ACLs in custom/editinit does not fire. Splat.

This is not happening for everyone (yet?) and I am mystified.

Any ideas? Anyone seen (and hopefully solved) anything like this before?

--
Paul Nagai

[ClayHelberg]

Hi Paul-



Maybe this is a red herring, but don't you need a "%1" somewhere in the
command you assign using ftype? In other words, shouldn't the command
be:



ftype xmlfile="C:\Program Files\Arbortext\Editor52\bin\epic.exe"
-newinstance %1



I think leaving that out may explain why it's invoking editor but not
loading the file you clicked.



--Clay

[naglists]

Hey Clay,
It looks like I didn't update my e-mail (stored in draft for a few days as
the problem developed) before sending it.

The command we are now using is actually:

ftype xmlfile=”C:\Program Files\Arbortext\Editor52\bin\epic.exe”

The -newinstance definitely caused a problem. The %1 is present on many,
many, but not all ftypes (you can dump them to file by typing "ftype >
c:\ftypes.txt" at a command prompt). On my system, where this
ftype/association works, there is no %1. I will add it to a broken system
and see if it fixes the problem.

[bibach]

Hey, Paul...

A quick look at the help for ftype didn't reveal the detail I was looking for, but I suspect that a command without any %1 (or other percent-escapes) gets treated as if there were a %1 on the end. The issue I'd be concerned about is paths and/or file names with spaces, which I'd account for by surrounding the %1 in quotes, just like the name of the executable. If adding %1 to the ftype command doesn't help, try adding "%1", instead.

-Brandon 🙂

[naglists]

Thanks, Clay. thanks, Brandon.

Appending "%1" to the ftype xmlfile blah blah blah fixed the "broken"
workstation. Now testing the fix wider but I'm pretty confident it'll solve
the problem everywhere.

I can't explain why it worked without the "%1" on some workstations and not
others.

[naglists]

Note to self: Don't forget that "%1" must be "%%1" in a batch file. Duh.