bytes or chars ?

[Robert Brenstein]

>  > If bytes must be for UTF8, then I resign to having bytes all over the
>>  place. BUT... then kernel must be able to tell me how many bytes as
>>  well as how many chars are actually in each field. I want also
>>  built-in functions that allow me to make char-byte count conversions
>>  for my GUI. We seem to agree that aside from storage, we will
>>  continue to deal with characters.
>
>If we decide that property
>
>     Vfield.MaxLenth must be in bytes, then it will return you bytes.
>
>Then I think better to use
>
>     Vfield.MaxBytes -- this is on disk...
>
>Robert, in fact we should not have nothing special in kernel.
>In REALbasic we will return Strings. It self know its encoding, length in
>chars and so on.

Ruslan, you did not understand me I think.

a)

For fields, we have Field_GetLength (should really be GetMaxLength).

It will, after change, return the number of bytes not chars as you say.

For BLOB fields, we have BLOB_GetDataSize.

This already returns number of bytes.

I am suggesting Field_GetDataSize (generalized version of 
BLOB_GetDataSize) and Field_GetCharCount so I can know how much 
data/chars is in a given VarChar or Text field.

Is it unreasonable to inquire this (if needed) instead of actually 
fetching the data into a local variable and counting in my code?

b)

If I get a string from user, I may need to know whether it fits into 
a given field. Thus, I'd like a function like 
Utility_GetDataSize(usertext,"UTF-8") which tells me the byte count 
required for storage.

Is it unreasonable to ask kernel to tell me that using the very same 
routines that will actually do the conversion?


>What about Revolution? It support unicode already?

Revolution supports unicode to some degree (as optional encoding for 
fields and variable content). I don't think it will switch to unicode 
as the base encoding in a near future though (I can be wrong).

>In any case we return to environment a string in the format which that
>environment understands. So you simply work with your native strings.

Of course.

Robert