--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > > --- In [email protected], "Sheri" <sherip99@> wrote: > > > The way you have proposed to do it (strings are returned as ANSI > > except when the content has high value characters), any script > > that enables unicode return-strings would need to test the > > content of each returned string to see if it looks like > > "u\x53nnn". If the script wants to handle unicode, why not let it > > declare that's what it wants and let it handle even low value > > characters as unicode? Otherwise the same function called in a > > loop sometimes returns a unicode handle and sometimes not! > > I accept your point. But should the new option mean that one > returns _all _ results (excepting handles to com objects) as > unicode strings? Or only those results that are meant to be > BSTRs, leaving the VT_I4 and other numeric types alone? I assume > the the latter.
Sounds reasonable that only said BSTRs would be potential conversion targets for unicode. I think I will be able to easily test the new feature when available with local teststring=myselect.contents (where myselect is a textframe and contents is a property) Currently it comes back as an ANSI string that debugs with one conversion issued question mark. I can also easily alter the contents and re-retrieve it to see what happens. For example, what happens if the textframe content string is a digit or two? Regards, Sheri
