Ben Combee wroteL > > The problem with such warnings, even minor, is that when > > running POSE's Gremlins, they stop the event sequence. > > > > The offending character is B0 (degree sign.) Does it become > > 0x00B0 or 0xFFB0 when converted into a WChar by StrChr?
> StrChr doesn't do the conversion -- the conversion is done by C > before the call. In theory it should go like: > (signed char) 0xB0 -> (signed int) 0xFFB0 -> (unsigned int) 0xFFB0 > with normal conversions > Your cast should subvert that and give you > (signed char) 0xB0 -> (unsigned char) 0xBO -> (unsigned int) > 0x00B0 > What seems to be failing is the conversion before the call... > I don't know why that would fail, it's probably bad code being > generated by the compiler -- maybe it's generating a load sign > extended all of the time to read the 8-bit value into the 68K > register. We'd need to see the disassembly from that function > to see what's happened. Yes, my impression was that the double cast would insure a proper unsigned 16-bit extension. Anyway, I just wrote a macro: #define ToWChar( c ) ( ( WChar ) ( unsigned char ) c ) & 0x00ff which suppresses warnings. Of course it only works with single-byte characters, but that's all I use. It's a little added code, but then nothing else gets executed in the API to handle a negative WChar. And I can let POSE report warnings (others may be interesting.) Luc Le Blanc -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
