E.g. "32-48" -> 32.0
This string parsing behavior is maybe acceptable for strings being passed into a math function, but it's completely unacceptable here. Also, it's useful for debugging to be able to get hexadecimal UNIDs, rather than converting them to int32.
Edit:
I'd suggest xmlGetAttrib should only convert to a number if all the characters in the string are numerals, except for up to one E/e (which isn't first or last), up to one decimal point (before the E if present and not first), and up to two - signs (only at the start and directly after an E).
Math and equality functions should probably convert valid hexadecimals, but otherwise they could use the same standard.
Workaround: replace xmlGetAttrib calls with this function:
(setq NMS_xmlGetAttrib (lambda (xml attrib)
(block (string pos)
(setq string (convertTo 'string xml))
(setq string (subset string 0 (strFind string ">")))
(if (setq pos (strFind string (cat " " attrib '=)))
(block (quoteType)
(setq string (subset string pos))
(setq quoteType (subset string (add (count attrib) 2) 1))
(setq string (subset string (add (count attrib) 3)))
(subset string 0 (strFind string quoteType))
)
Nil
)
)
))
I've fixed xmlGetAttrib in 1.8 Beta 1 so that it does not convert strings to numbers unless the whole string is a number. [This was the original intent, but there was a bug.]