Actually, yes, htmlText should be fine - for some reason I have it in my head its not fully faithful, but 5.5 should have made it so.Hmm... Isn't htmlText a complete representation of styledText? At least in the context I'm using it in it's much easier to work with because I don't need to worry about encoding... for styledText I'd need to parse it for unicode and utf8 it... I do realise it's not just me using this thing and I could delete the key and add htmlText but htmlText is already there and if it doesn't lose any data then it would be good to stick with it...
I only threw that out there as a potential suggestion... I guess it doesn't do any harm because, as you say, the id will be set if it can or just error-out silently.I agree with @mwieder about ID... I think that should be in there because we don't know the context of how and where the properties will be set and the error lock is on during setting anyway...
In regards to Unicode - internally the engine does use UTF-8 in places for convenience of implementation. However, the 'unicode' properties are host byte-order UTF-16 - and this is what should be returned.Hmm... OK, I don't think it will impact me a great deal... it's a little frustrating that the data appears to be utf8 encoded no matter what and that's what I want to end up with but to get it I'd need to implement a whole separate property... I guess hasunicode() is my friend?
Basically, if an object's 'hasunicode()' method returns true, it means that it should present unicode properties, rather than non-unicode ones.
I think the 'style' property overlaps with other flags on some objects - which is what I had in mind when I wrote that. I'll need to double-check.Can you give me an example of overlapping properties that require both? I can't think of any at the moment.
[ As an aside, Unicode gets 'solved' by the refactor we are doing - rather than changing everything to UTF-8 internally which would cause all kinds of problems with efficiency and backwards-compatibility, strings are being changed to be an opaque MCStringRef type that can be either native or Unicode. This is a little more work, but will give a much better forward-compatibility experience - stacks that work with just native text should (for the most part) carry forward and 'just work' with Unicode text. ]