On Tue, 20 Nov 2007, Graeme Geldenhuys wrote:
> On 20/11/2007, Michael Van Canneyt <[EMAIL PROTECTED]> 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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel