Using overrides is the method I am using to try and minimize this negative
consequences here.

This will balloon the code considerably to continue doing this more but that
is a better price to pay than in performance.

Regards,
Jason Wharton

----- Original Message -----
From: "Hans" <hhoogstraat@...>
To: <IBObjects@yahoogroups.com>
Sent: Sunday, April 05, 2009 11:35 AM
Subject: Re: [IBO] IBO - IB_String vs AnsiString


> Is it possible to declare a new overriden variable
> type or function wrapper, to change these 'strings'
> to, which then automatically compiles into the
> proper String or AnsiString ? This change to your
> code would would only be required once.
>
> Alike Jason overrode many of the functions in 4.9
>
> ----- Original Message -----
> From: "m. Th." <th@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Sunday, April 05, 2009 10:04 AM
> Subject: [IBO] IBO - IB_String vs AnsiString
>
>
>> Hi,
>>
>> The ones who have the IBO 4.9 know that many String types where changed
>> to AnsiString.
>>
>> While this is understandable, taking in account the amount of work
>> required, this is unfortunate in certain areas like the ones who deal
>> with the query parsing. I mean primarily code blocks (methods,
>> procedures etc.) like Get/SetSQLWhere, SQLOrder etc. This means that
>> when we use these code blocks we cannot use Unicode.
>>
>> But the problem here is that the _interface_ (iow the declaration) of
>> these code blocks is changed. So we must change our variables to
>> AnsiString in order to compile.
>>
>> There are some solutions here:
>>
>> 1. To use in _our_ code a string type like IB_String = AnsiString and
>> when change it gradually to String when the library changes it's
>> interface.
>>
>> 2. To use in _library's_ code the same approach as above. The 2nd has
>> also the advance that we'll know where are the places in the library
>> where 'AnsiString' must be changed back and where it must stay
>> 'AnsiString'.
>>
>> Thoughts? Comments?
>>
>> m. Th.