Topic Title

Interesting. I believe attribute names are supposed to be limited to 12 characters ... so what's up here? I'm surprised it is not producing an exception error.
I am still working in D4D in other areas, but expect to get back to some attribute work in a couple weeks. I'll check out this behavior in D4D and add my results then.

Yes, atrname is a 12 character string. The length of the string is stored in the first byte of the string variable (and this is what strlen is returning), so it is feasible to set it to a number greater than the allowable length without actually causing an error. But any subsequent use of the string is likely to (and did in my case) cause problems.
Will be interesting to see if you find the same behaviour in D4D (at least it should be easy to debug in Delphi ... I spent considerable time tracking down exactly what was causing my problems). I might have written my current project in D4D if the modeGroup bug had been fixed 7 or 8 months earlier, and it would have been a lot easier to debug if I had (but I'm a long way down the track now, and not really inclined to convert to D4D).
Rgds,
David H.

I believe that shortStrings (aka str255) hold the length in the string [0] position and that this byte is not counted in calls to strlen (at least according to the DCAl manual = see string discussion on pg 28/29). Delphi
s length method does the same thing. Does your returned atr.name value have an additional space added when it is returned with an extra character in its length?

Yes, you are correct about the length in the [0] position ... that is what I meant by the first byte of the variable, although perhaps my wording was a bit ambiguous. The atrname written to my log file has an extra space added to the end (at position 13 or the 12 character string), and strlen returns 13. I think this is more due to the length byte (offset 0) being changed to an invalid value rather than a space being appended to the string as such. The 'adding' of a space or any other particular character may be more to do with the value of the adjacent variable in memory as I believe the variables are packed rather than word aligned (although in all cases where I have logged this it has been a space that has been written to the log file and not any other character).