2007/11/14, Stefan Heymann <lists@...>:

>
> > Hence, the UTF-8 will already be the correct character set for the
> > data-bound controls, provided that the developer has set it
> > correctly.
>
> IMHO this should be "Provided that the developer has set the Client
> Character Set property correctly, fbclient.dll will already deliver
> the correct character set".

Obviously.

> > This means that IBO does not play a role in this game, because the
> > conversion is already done by the fbclient-API.
>
> No. The fbclient doesn't have to convert anything when the database is
> in UTF-8 and the client connection is in UTF-8.

I meant to say "because the conversion, if necessary, is already done
[...]", of course.

> > There's one pitfall, though: If the fbclient-API finds characters
> > that it was unable to transcode, it'll signal an error and the
> > current operation will be aborted.
>
> But only if the Client Character Set is not UTF8.

If the client's character-set is utf-8, there can not be a
transliteration-problem.

> > That's why I would prefer, in the case that I'm using
> > unicode-unaware controls and a unicode database, for IBO to do a
> > 'soft' conversion with loose error handling.
>
> I can understand what you mean. But having everything go through these
> events would be quite time-consuming.

No. If those events are not set, there'll be only a simple 'cmp' added
to the runtime. If the event is set to a trivial function, it'll be a
'cmp', a 'call' and a 'ret', basically.
And this is not a time-critical section of code, anyways. Thinking
about how the string arrived where it is now, a little cmp can
definitely be considered harmless. Remember that it had to be located
and read from the db, shipped over a network-layer and put into the
client-buffer and (if necessary) has been transcoded, already.

> However, I don't care as long as I can have unmodified UTF-8 ;-)

I, too, think that this has a high priority to make IBObjects usable
for more 'advanced' applications.

--
eat(this); // delicious suicide