Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2003-12

TReader.ReadPropValue

4 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Darek Mazur

I've try to discover why LRS don't work with TColor, and I think I found:

in ReadPropValue for enumeration identifier can't be a VALUE

this is my proposition to solve:

    tkEnumeration:
      begin
        Value := GetEnumValue(PropType, ReadIdent);
        if value = -1 then begin
          IdentToIntFn := FindIdentToInt(PPropInfo(PropInfo)^.PropType);
          Ident := ReadIdent;
          if Assigned(IdentToIntFn) then IdentToIntFn(Ident, Value);
        end;
        if Value = -1 then
          raise EReadError.Create(SInvalidPropertyValue);
        SetOrdProp(Instance, PropInfo, Value);
      end;

Darek

Reply by email

Mattias Gaertner
to Darek Mazur
Show quoted text 7 lines
I've try to discover why LRS don't work with TColor, and I think I found: in ReadPropValue for enumeration identifier can't be a VALUE this is my proposition to solve: tkEnumeration:

- TColor is not an enum
- Even FindIdentToInt will fail, for the simple reason that the ColorToInt/IntToColor functions can't be found. These functions are registered by the return value of TypeInfo(TColor), which should return one unique pointer for each type. But fpc 1.0.x and 1.9.x returns different values, depending on where you use the TypeInfo function. In this case: TypeInfo(TColor) called in graphics.pp returns a different value than called in classes.pp.
One solution would be to add a further list of IntToIdent functions identified by names instead of TypeInfo. The disadvantage is, that it can be ambgious. But since the TypeInfo registering does not work, it is not used, so this workaround will not break any code. And what is more important: These things are rarely used, so as soon as the TypeInfo works, we only need to change a few lines of code.

About the addition: I think, it can be useful for alias enums (e.g. myenum =
(a:=b, c:=d, ...) ). What do the fpc devels think about?

Mattias

Show quoted text 20 lines
begin Value := GetEnumValue(PropType, ReadIdent); if value = -1 then begin IdentToIntFn := FindIdentToInt(PPropInfo(PropInfo)^.PropType); Ident := ReadIdent; if Assigned(IdentToIntFn) then IdentToIntFn(Ident, Value); end; if Value = -1 then raise EReadError.Create(SInvalidPropertyValue); SetOrdProp(Instance, PropInfo, Value); end; Darek _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Florian Klaempfl
to Mattias Gaertner
Mattias Gaertner wrote
unique pointer for each type. But fpc 1.0.x and 1.9.x returns different values, depending on where you use the TypeInfo function. In this case: TypeInfo(TColor) called in graphics.pp returns a different value than called in classes.pp.

Submit a bug report and we'll fix it soon or later :)

Show quoted text 10 lines
One solution would be to add a further list of IntToIdent functions identified by names instead of TypeInfo. The disadvantage is, that it can be ambgious. But since the TypeInfo registering does not work, it is not used, so this workaround will not break any code. And what is more important: These things are rarely used, so as soon as the TypeInfo works, we only need to change a few lines of code. About the addition: I think, it can be useful for alias enums (e.g. myenum = (a:=b, c:=d, ...) ). What do the fpc devels think about?

The enums are still not compatible.

Reply by email

Mattias Gaertner
to Florian Klaempfl
Show quoted text 7 lines
Mattias Gaertner wrote: > unique pointer for each type. But fpc 1.0.x and 1.9.x returns different > values, depending on where you use the TypeInfo function. In this case: > TypeInfo(TColor) called in graphics.pp returns a different value than > called in classes.pp. Submit a bug report and we'll fix it soon or later :)

Done.

Show quoted text 12 lines
> One solution would be to add a further list of IntToIdent functions > identified by names instead of TypeInfo. The disadvantage is, that it > can be ambgious. But since the TypeInfo registering does not work, it is > not used, so this workaround will not break any code. And what is more > important: These things are rarely used, so as soon as the TypeInfo > works, we only need to change a few lines of code. > > > About the addition: I think, it can be useful for alias enums (e.g. > myenum =(a:=b, c:=d, ...) ). What do the fpc devels think about? The enums are still not compatible.

Ok. You need to map alias names to enum names instead and then use GetEnumName. OTOH this is just a goodie.

What about the alternative workaround for the integers? This is needed for streaming Delphi forms.

Mattias

Reply by email