Hi,
As I have been experimenting with setting the default signatures through the command line, I have come across something that isn't making sense.
I have a package of test data I am running Droid on. I also have 3 different signature files available in the sigs local folder (V104, V100 and V65). In each of these xml signature files I have edited one of the file types it will encounter in my package in order to be able to confirm it is running that specific signature file when I set it as the default at the command line. Example where I have added extra text to the name field:
<FileFormat ID="285" Name="V100-WordStar for MS-DOS Document"
PUID="x-fmt/205" Version="5.0">
<InternalSignatureID>610</InternalSignatureID>
<Extension>ws</Extension>
<Extension>ws5</Extension>
</FileFormat>
Each of the signature files have their specific version embedded at that line. When I set the default signature as either V100 or V65, this text shows up in the export file, which is what we would expect, but the moment I set it to V104, it does not show up. It removes that little bit of extra bold text and looks like the original version.
For a while it was V100 having this issue, so the fact that it's not consistent, tells me something else must be over-riding the signature you set depending on some unknown setting. I even tried doing an signature install directly in the Droid GUI of the adjusted V104, but it still doesn't output what you would expect.
And just to add a little more mystery, if I arbitrarily change the value in the V104.xml to 105 (ex: Version="105") and set this as the default in the command line, guess what? The text now shows up as expected!
I have noticed with Droid 6.5.2, if you delete all the signatures in the local user folder, the moment you open Droid it repopulates it with version V100.xml, which is fine and makes sense, but I'm wondering if that may be part of the problem I am witnessing (ie; there is an internally stored signature file ready to be used in case anything goes wrong).
So something is buggy here.... sorry for the wall of text.
Thanks again for your help!
Matthew