There surely is a logic in it, but I can't recognize it.
Pls wait a little, I'm converting GT USHORTs to int. I'd appreciate
if
you'd review it.
It doesn't matter what we agree as base text holder.
Important is to respect pure C behavior in casting.
if we have:
int iValue = ( UCHAR ) hb_parcx( 1 )[ 0 ];
and you change it to:
int iValue = ( int ) hb_parcx( 1 )[ 0 ];
then for chr( 255 ) passed as 1-st parameter iValue will be -1 instead
of 255 on machines where char is signed value.
Similar situation happens when you change:
[const] char* szText;
...
( UCHAR ) *szText
to:
( USHORT ) *szText
This will introduce problems for GTs which will store Unicode
values in screen buffer and will not ignore upper byte of character.
Okay, I get it, at least the first part.
Anyhow, do you think we should reduce the variations of text
representation inside the GT? also for color.
color should probably be int (instead of BYTE) in every API
call, and text should be 'char' (instead of USHORT, UCHAR, int)
in every API call.
What do you think?
I still have two pending commit to GTWIN and GTWVT, because these
used SHORTs internally. Also should be done GTWVG, but I'm too
tired now for it.
As a next step it'd be also great to clean ULONG/LONG as string/array
index to hbSize.
Many thanks for the fixes and review.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
