[fpc-devel] RTTI's GetPropValue returns corrupt Boolean value

Michael Van Canneyt michael at freepascal.org
Tue Nov 20 15:41:24 CET 2007



On Tue, 20 Nov 2007, Graeme Geldenhuys wrote:

> On 20/11/2007, Michael Van Canneyt <michael at freepascal.org> wrote:
> > It's hard to say whether this is an actual error or an incompatibility.
> 
> Well this 'error' has been around in tiOPF since I ported it to FPC
> (about 3 years) and now it's really bugging me.  :)
> 
> > Looking at the code and the error, I'd say that somewhere along the line
> > fpc converted a variant to int64 instead of to an integer as delphi seems
> > to do.
> 
> No idea, I may not look at the Delphi code remember!  ;-)

Point scored :-)

> 
> 
> > It's just one of these reasons why it is IMHO better not to use Variants:
> > things happen behind the scenes that are not very clear (and that are
> > not documented )
> 
> Fair enough. I'm not a fan of Variants either, but how else would I
> write the PropertyMatch() function then?  Yes I could do some extra
> tests and use GetStrProp, GetIntProp, GetFloatProp etc. 

This is IMHO the only correct way.

> but there
> isn't a GetBooleanProp().  I would imagine I need to use the
> GetOrdProp for Boolean, but looking at the function definition for
> GetOrdProp, it outputs a Int64 which is probably what gave me the
> error in the first place (casting Bool to Int64 or vice-versa).

It probably retuns an int(64), and when it's converted to variant 
- I don't know. I'd have to look at the code.

> 
> Note that the PropertyMatch() function I have in the example is a
> scaled down version (just to highlight the issue) of the full one in
> tiOPF.  I need to handle all property types.

This is exactly where the easy access to RTTI would come in handy, and 
which is why I would like to have it. If you want we can always discuss
in private the design of such an easy-acces method.

Michael.



More information about the fpc-devel mailing list