Sign in Join

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

Mailing lists / lazarus / 2020-11

AutoCommit

17 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

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

Larry Dalton

Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’

Sent from my iPhone

Reply by email

Larry Dalton
to Larry Dalton

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

Show quoted text 5 lines
On Nov 13, 2020, at 10:58, Larry Dalton wrote: Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’ Sent from my iPhone

Reply by email

Larry Dalton
to Larry Dalton

I forgot to add that it compiles correctly, but then I get the runtime error

Sent from my iPhone

Show quoted text 11 lines
On Nov 13, 2020, at 11:02, Larry Dalton wrote: 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 > On Nov 13, 2020, at 10:58, Larry Dalton wrote: > > Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’ > > Sent from my iPhone

Reply by email

Michael Van Canneyt
to Larry Dalton

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.

Larry Dalton wrote 20 lines
I forgot to add that it compiles correctly, but then I get the runtime error Sent from my iPhone > On Nov 13, 2020, at 11:02, Larry Dalton wrote: > > 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 > >> On Nov 13, 2020, at 10:58, Larry Dalton wrote: >> >> Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’ >> >> Sent from my iPhone -- _______________________________________________ lazarus mailing list https://lists.lazarus-ide.org/listinfo/lazarus

Reply by email

Larry Dalton
to Michael Van Canneyt

So we lose some backwards portability?

Sent from my iPhone

Show quoted text 26 lines
On Nov 13, 2020, at 11:06, Michael Van Canneyt wrote:  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. > On Fri, 13 Nov 2020, Larry Dalton via lazarus wrote: > > I forgot to add that it compiles correctly, but then I get the runtime error > Sent from my iPhone > >>> On Nov 13, 2020, at 11:02, Larry Dalton wrote: >> 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 >>> On Nov 13, 2020, at 10:58, Larry Dalton wrote: >>> Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’ >>> Sent from my iPhone > -- > _______________________________________________ > lazarus mailing list > > https://lists.lazarus-ide.org/listinfo/lazarus

Reply by email

Larry Dalton

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

Show quoted text 44 lines
On Nov 13, 2020, at 11:34, Michał Gawrycki wrote: Remove this property from lfm file and set it by code if needed (maybe along with ifdef). Michał. W dniu 2020-11-13 o 17:19, Larry Dalton via lazarus pisze: > So we lose some backwards portability? > Sent from my iPhone >>> On Nov 13, 2020, at 11:06, Michael Van Canneyt wrote: >> >>  >> 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. >> >>> On Fri, 13 Nov 2020, Larry Dalton via lazarus wrote: >>> >>> I forgot to add that it compiles correctly, but then I get the runtime error >>> Sent from my iPhone >>> >>>>> On Nov 13, 2020, at 11:02, Larry Dalton wrote: >>>> 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 >>>>> On Nov 13, 2020, at 10:58, Larry Dalton wrote: >>>>> Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’ >>>>> Sent from my iPhone >>> -- >>> _______________________________________________ >>> lazarus mailing list >>> >>> https://lists.lazarus-ide.org/listinfo/lazarus -- GM Systems ul. K.Marksa 9 58-260 Bielawa tel. +48 694 178 276 http://www.gmsystems.pl/

Reply by email

Michael Van Canneyt
to Larry Dalton: So we lose some backwards portability? Sent from my iPhone

Yes, but that's always so when properties are added to components.

Michael.

Larry Dalton wrote 31 lines
So we lose some backwards portability? Sent from my iPhone > On Nov 13, 2020, at 11:06, Michael Van Canneyt wrote: > >  > 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. > >> On Fri, 13 Nov 2020, Larry Dalton via lazarus wrote: >> >> I forgot to add that it compiles correctly, but then I get the runtime error >> Sent from my iPhone >> >>>> On Nov 13, 2020, at 11:02, Larry Dalton wrote: >>> 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 >>>> On Nov 13, 2020, at 10:58, Larry Dalton wrote: >>>> Error code “Project ****** raised exception class ‘EReadError with unknown property ‘AutoCommit’ >>>> Sent from my iPhone >> -- >> _______________________________________________ >> lazarus mailing list >> >> https://lists.lazarus-ide.org/listinfo/lazarus

Reply by email

Ondrej Pokorny
to Michael Van Canneyt

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

Michael Van Canneyt wrote 47 lines
Yes, but that's always so when properties are added to components. Michael. On Fri, 13 Nov 2020, Larry Dalton wrote: > So we lose some backwards portability? > > Sent from my iPhone > >> On Nov 13, 2020, at 11:06, Michael Van Canneyt >> wrote: >> >>  >> 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. >> >>> On Fri, 13 Nov 2020, Larry Dalton via lazarus wrote: >>> >>> I forgot to add that it compiles correctly, but then I get the >>> runtime error >>> Sent from my iPhone >>> >>>>> On Nov 13, 2020, at 11:02, Larry Dalton >>>>> wrote: >>>> 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 >>>>> On Nov 13, 2020, at 10:58, Larry Dalton >>>>> wrote: >>>>> Error code “Project ****** raised exception class ‘EReadError >>>>> with unknown property ‘AutoCommit’ >>>>> Sent from my iPhone >>> -- >>> _______________________________________________ >>> lazarus mailing list >>> >>> https://lists.lazarus-ide.org/listinfo/lazarus >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201113/bdb91806/attachment.html>

Reply by email

Juha Manninen
to Larry Dalton: 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>

Reply by email

Michael Van Canneyt
to Ondrej Pokorny: Usually we try to use the "default" feature of the newly added properties so that they…
Ondrej Pokorny wrote
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.

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.

Reply by email

Sven Barth
to Michael Van Canneyt

Michael Van Canneyt via lazarus schrieb am
Fr., 13. Nov. 2020, 22:37:

Show quoted text 17 lines
On Fri, 13 Nov 2020, Ondrej Pokorny via lazarus wrote: > 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. 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'.

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>

Reply by email

Ondrej Pokorny
to Michael Van Canneyt: I set defaults on all boolean properties of sqlscript, rev. 47412 Strange, I thought that…
Michael Van Canneyt wrote 10 lines
On Fri, 13 Nov 2020, Ondrej Pokorny via lazarus wrote: > 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. 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'.

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>

Reply by email

Ondrej Pokorny
to Juha Manninen: On Fri, Nov 13, 2020 at 6:19 PM Larry Dalton via lazarus < IIRC it has been called…
Juha Manninen wrote 13 lines
On Fri, Nov 13, 2020 at 6:19 PM Larry Dalton via lazarus < <mailto:>> 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.

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>

Reply by email

Michael Van Canneyt
to Ondrej Pokorny: The FPC documentation is spot on about the stored/default modifiers:…
Ondrej Pokorny wrote 17 lines
On 13.11.2020 22:37, Michael Van Canneyt via lazarus wrote: > On Fri, 13 Nov 2020, Ondrej Pokorny via lazarus wrote: >> 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. > > 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'. 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./"

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.

Reply by email

Ondrej Pokorny
to Michael Van Canneyt
Michael Van Canneyt wrote 7 lines
On Sat, 14 Nov 2020, Ondrej Pokorny wrote: > 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.

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>

Reply by email

Michael Van Canneyt
to Sven Barth: Michael Van Canneyt via lazarus schrieb am Fr., 13. Nov. 2020, 22:37: No, cause their…
Sven Barth wrote 23 lines
Michael Van Canneyt via lazarus schrieb am Fr., 13. Nov. 2020, 22:37: > > > On Fri, 13 Nov 2020, Ondrej Pokorny via lazarus wrote: > >> 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. > > 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'. > No, cause their intended default value could be True. Thus no special handling for them.

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.

Reply by email

Ondrej Pokorny
to Michael Van Canneyt
Michael Van Canneyt wrote 14 lines
On Sat, 14 Nov 2020, Sven Barth via lazarus wrote: > No, cause their intended default value could be True. Thus no special > handling for them. 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.

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

Reply by email