[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