> This fixed a bug in labels with the %M format. Formerly it was
> inserting the full model name, which could be very long, into the %M
atom label format.
OK ... that makes sense for %M formatting
> (Which reminds me, please redo my fix of %m.)
This was reintroduced in the 10.00.50 release
> Please redo that fix. There are some reader files fixes that go along
with this, as I recall. Check the commit trail.
%M will now report modelTagNumber instead of modelTag.
The implementation of getModelTagNumber() is another question.
> I believe I made the
> distinction now between modelTag and modelTagNumber. That's important.
getModelTagNumber() already existed.
Here is the diff ...
int getModelTagNumber() {
- try {
- return Integer.parseInt(group.chain.model.modelTag);
- } catch (NumberFormatException nfe) {
- return modelIndex + 1;
- }
+ if (group.chain.frame.isPDB) {
+ try {
+ return Integer.parseInt(group.chain.model.modelTag);
+ } finally {}
+ }
+ return getModelNumber();
}
The old code would return number if the model tag was *exactly* an integer.
The new code only tries to do this conversion if the file is a .pdb file
The question is ... what should the appropriate behavior be?
If the modelTag in the file is "4567" then I think that the modelTagNumber
should be 4567 ... regardless of the file type ... so that the
modelTagNumber reflects the number in the file if it is a number.
Q: Do you agree?
Miguel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
