Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’
Sent from my iPhone

Mailing lists / lazarus / 2020-11
17 messages · 5 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’
Sent from my iPhone
This is only when I try to compile on Lazarus 2.0.6 on Windows. The project works fine on 2.0.10 on Linux. Any ideas?
Sent from my iPhone
I forgot to add that it compiles correctly, but then I get the runtime error
Sent from my iPhone
Your .lfm file contains a property "autocommit" that exists in 2.0.10 but not in 2.0.6. I think 2.0.10 is based on FPC 3.2.0 and 2.0.6 was still based on 3.0.4.
A lot of new properties appeared between 3.0.4 and 3.2.0.
Michael.
So we lose some backwards portability?
Sent from my iPhone
This problem was brought to light when I couldn’t get 2.0.10 apps to hook up to MySQL on Windows. I have no problem on my Linux box.
Sent from my iPhone
So we lose some backwards portability? Sent from my iPhone
Yes, but that's always so when properties are added to components.
Michael.
Usually we try to use the "default" feature of the newly added properties so that they are streamed only when really set and used. When they are not used, the LFM can still be loaded in a legacy version of Lazarus because the new properties are not streamed.
Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201113/bdb91806/attachment.html>
So we lose some backwards portability? Sent from my iPhone
On Fri, Nov 13, 2020 at 6:19 PM Larry Dalton via lazarus <
wrote: So we lose some backwards portability?
IIRC it has been called "forward compatibility" as opposed to "backward compatibility".
Backward compatibility means your old code works in new versions of FPC/LCL/Lazarus.
The other direction is not guaranteed. New code cannot always be used in old versions.
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201113/747d244e/attachment.html>
Usually we try to use the "default" feature of the newly added properties so that they…
Ondrej Pokorny wroteUsually we try to use the "default" feature of the newly added properties so that they are streamed only when really set and used. When they are not used, the LFM can still be loaded in a legacy version of Lazarus because the new properties are not streamed.
I set defaults on all boolean properties of sqlscript, rev. 47412
Strange, I thought that boolean properties were not streamed if they had value 'false'.
Michael.
Michael Van Canneyt via lazarus schrieb am
Fr., 13. Nov. 2020, 22:37:
No, cause their intended default value could be True. Thus no special handling for them.
Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201114/826589cb/attachment.html>
I set defaults on all boolean properties of sqlscript, rev. 47412 Strange, I thought that…
The FPC documentation is spot on about the stored/default modifiers: https://www.freepascal.org/docs-html/ref/refsu38.html
Only "/String, floating-point and pointer properties have implicit////default//value of empty string, 0 or nil, respectively. Ordinal and set properties have no implicit//default//value./"
I polished the docs section in r1777 a little bit.
Then I saw the next chapter "Overriding properties". It wrongly described redeclaring of properties as overriding. I fixed that as well in r1778.
Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201114/de6ad0a1/attachment-0001.html>
On Fri, Nov 13, 2020 at 6:19 PM Larry Dalton via lazarus < IIRC it has been called…
Exactly.
Although in case of LFM streaming we usually try to help with default property values as we discussed before. And yes, I usually forget to add the default values as well :)
Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201114/be93769b/attachment.html>
The FPC documentation is spot on about the stored/default modifiers:…
Indeed.
I polished the docs section in r1777 a little bit.
Well done, thank you !
Then I saw the next chapter "Overriding properties". It wrongly described redeclaring of properties as overriding. I fixed that as well in r1778.
I think the difference is rather artificial, but if you think this is better: great.
Thank you for your efforts !
Michael.
You are right. I didn't know one can override also read/write specifiers (I thought one must redeclare the property in that case):
TAncestor = class(TComponent)
private
fPropName: string;
published
property PropName: string read fPropName write fPropName; end;
TOverride = class(TAncestor)
private
fPropName2: string;
published
property PropName read fPropName2 write fPropName2; // no type declaration
end;
But anyway as stated in the Delphi docs
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Properties_(Delphi)#Property_Overrides_and_Redeclarations :
/Whether a property is hidden or overridden in a derived class, property look-up is always static./
So you are right - there is no real difference in property override/reintroduce like there is override/overload/reintroduce difference in object methods.
I'll make that more clear in FPC docs.
Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201114/1eec7094/attachment.html>
Michael Van Canneyt via lazarus schrieb am Fr., 13. Nov. 2020, 22:37: No, cause their…
You can of course say the same for all other types for which an implicit 'default' is implemented. The more so because a class is initialized with 0 in which case every enumerated and boolean will be ord(0) unless otherwise initialized in the constructor.
So I don't see why this rule is not applied to all properties, I don't think it is logical.
Michael.
I agree. One would not expect the implicit default values for string/real/pointer properties.
And then people wonder why their empty string properties are not streamed:
TMyClass = class
published
property MyString: string read FString write FString stored
IsMyStringStored;
end;
constructor TMyClass.Create;
begin
FMyString := 'abc';
end;
function TMyClass.IsMyStringStored: Boolean;
begin
Result := FMyString'abc';
end;What's wrong?
-> The nodefault is missing in order the empty string be streamed: property MyString: string read FString write FString stored IsMyStringStored nodefault;
Not logical, not intuitive, but that is how it works and is documented :/
Ondrej