Re: [Lazarus] Form events firing order and count

[José Mejuto via Lazarus]

El 25/02/2018 a las 9:03, Gabor Boros via Lazarus escribió:

For me the good order is the real order independently from the other 
widgetsets. For example at form maximize, the form moved to 0,0 
coordinates then it's size increased. At form restore, form's size 
decreased then moved to the correct place. So at maximize the order is 
moved, resized, statechanged and at restore resized, statechanged, moved.


Hello,

Events order is mostly a matter of taste, for me the order should be 
statechange (so programmer can cancel the operation before it happens, 
if possible), move, resize.


Is the development process of LCL-fpGUI public or viewable just when 
committed into Lazarus trunk?


I'm the only one working in LCL-fpGUI and I'm contributing using patches 
so the "advances" are not visible in real-time. If you are interested in 
the advances I can pack my develop folder and send it to you by mail 
when something more or less important is changed. The folder is mostly 
in unstable state because some features need a lot of try/error with a 
bunch of writelns all over different units.


Last advance is Hi-DPI support (under testing) and the possibility to 
compile with develop branch but with this branch some things do not work 
as expected (I think they are bugs in fpGUI and I'm writting sample code 
to send to Graeme so he can decide if its a bug or not).


--

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[R0b0t1 via Lazarus]

On Mon, Feb 19, 2018 at 7:09 AM, Ondrej Pokorny via Lazarus
 wrote:
> True words. IMO we can apply the same to LCL events: the order/count is an
> implementation detail and depends on the underlying widgetset.
>

I agree, and am glad to find this was brought up. On the other hand, I
think it would be good to know what is going on in the event loop of
the application. There are some inconsistencies in naming and how
threading "works" or does not work that I am still baffled by. This is
likely not a Lazarus issue, and may be something inherited from
Delphi.

I think the goal could be aided with a high level document on what is
going on, as I've had it explained to me a number of times but am
still confused.

Cheers,
 R0b0t1
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

> I will mention 1 case in point. Const parameters.
> 
> For years, people mistakenly assumed that Const parameters were 
> be passed by reference if they were "big" (records), a behaviour which
> Delphi exhibited.
People actually believed that? When the documentation explicitly stated that var
parameters are the *only* byrefs, everything else being passed by value (which
technically makes the special case for large objects a bug)? Oh well.

One might argue if code is documentation for EOL products - they can't change
their minds about Turbo Pascal any more. And with the long standing policy of
being source-code compatible all the way back, that should mean something
regarding the same language constructs in current versions. But still, Delphi is
a moving target, and some things have long branched way past the point where one
might aim to be "compatible".

Why do I feel we're both arguing the same side here? ;-)


--Martok

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Michael Van Canneyt via Lazarus]

On Mon, 19 Feb 2018, DougC via Lazarus wrote:


 On Mon, 19 Feb 2018 13:47:14 -0500 Michael Van Canneyt via Lazarus 
lazarus@lists.lazarus-ide.org wrote 

And documented behaviour is what the language guide of Delphi states.

Is there such a language guide for the language features introduced in the last 
10 years?

AFAIK the last one was published around 2002 so this is hardly a good basis.


The Delphi help is the only documentation available these days, so what you
find in that, this is it...

Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[DougC via Lazarus]

 On Mon, 19 Feb 2018 13:47:14 -0500 Michael Van Canneyt via Lazarus 
lazarus@lists.lazarus-ide.org wrote 




And documented behaviour is what the language guide of Delphi states.




Is there such a language guide for the language features introduced in the last 
10 years?

AFAIK the last one was published around 2002 so this is hardly a good basis.




-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Michael Van Canneyt via Lazarus]

On Mon, 19 Feb 2018, Martok via Lazarus wrote:


Am 19.02.2018 um 11:10 schrieb Sven Barth via Lazarus:
As long as the code does not rely on undocumented behavior, yes. 

And therein lies the issue. Things that worked the same way for >25 years and
are mentioned explicitly in numerous secondary literature are considered
"undocumented".


I will mention 1 case in point. Const parameters.

For years, people mistakenly assumed that Const parameters were 
be passed by reference if they were "big" (records), a behaviour which

Delphi exhibited. And 'mentioned explicitly in numberous secundary
literature' as you put it so nicely. But not documented.

FPC introduced Constref to guarantee a constant was passed by
reference (I think IUnknown methods were the first to use this), 
but otherwise refused to change our view of 'Const'.


Then one day, someone on the Delphi team (I believe Allan Bauer?) makes a
blog post stating that "Const never implied that big types are passed by
reference", and that people should correct their code and use the new [Ref]
attribute if they want a const parameter passed by reference.

Thus supporting the point of view which we had all along.

So, no, we will not promise to conform to undocumented behaviour.

And documented behaviour is what the language guide of Delphi states.

So unless Delphi _documents_ that

MyClass.SomeInterfaceExpression.SomeMethod;

is 100% equivalent to

Temp:=MyClass.SomeInterfaceExpression;
try
  Temp.SomeMethod;
finally
  Temp:=Nil;
end;

It remains an implementation detail when the temp is finalized.

Which, in FPC, is currently at the end of the procedure.

Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

Am 19.02.2018 um 11:10 schrieb Sven Barth via Lazarus:
> As long as the code does not rely on undocumented behavior, yes. 
And therein lies the issue. Things that worked the same way for >25 years and
are mentioned explicitly in numerous secondary literature are considered
"undocumented". And whatever is the official documentation anyway - the
yellow-{blue,red} books? .hlp? .hxs? Docwiki? And in which translation?

Don't get me wrong: I *get* why the choices that were made needed to be made to
get cross-platform consistency within fpc. I even agree with most of them. I
just think it would be dishonest to pretend they weren't made. That was the
entire point of my earlier post.


Am 19.02.2018 um 13:51 schrieb Michael Van Canneyt via Lazarus:
> Do you have examples where it does not ?
I listed some right below. Mind you, none of them are esoteric corner-cases: the
Interface stuff is any LINQ-alike ever, PixelFormat means Scanline and blit
performance, etc.

>> That's kinda the opposite of what the technical definition of
>> "source-code compatible" means.
> Really? Where did you find this definition ?
Wikipedia. They make it about portability of the function of a program across
platforms (read: compilers).

> And that's all there is to say about it.
Indeed it is. Once one internalizes that there is at best accidental
compatibility, a lot of pain goes away. Just treat fpc as a completely different
language system with some deceptively named syntax modes, and you end up with a
pretty great compiler.

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Ondrej Pokorny via Lazarus]

On 19.02.2018 13:51, Michael Van Canneyt via Lazarus wrote:
If your code relies on implementation details, it won't always work 
obviously.


But if you spot differences in behaviour, you can notify the devs. 
There are

then 2 options:
- They try to fix the behaviour.
- They explain why it works differently.

And that's all there is to say about it.


True words. IMO we can apply the same to LCL events: the order/count is 
an implementation detail and depends on the underlying widgetset.


Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Michael Van Canneyt via Lazarus]

On Mon, 19 Feb 2018, Martok via Lazarus wrote:


Am 19.02.2018 um 00:18 schrieb Michael Van Canneyt via Lazarus:

Why is it obviously not true ? It's obviously not true that it is compatible
at the binary level. FPC does not produce the same binary code

I'm more talking about the macroscopic perspective. Of course the binary code
may be different, but does it have the same concept of what a specific block of
source "means"?


It should.

It's obvious that if CloseFile() under the hood actually does nothing, this
is not what it 'means'.

The examples you give are in a gray zone, where "what it means" is not always so
clear.



Or, put differently,

But source code written for Delphi must compile in FPC.

Should it also do something *similar*?


Do you have examples where it does not ?



Just from the things that come up at least twice a year in the time since I
started actively following the lists... tempvar allocation and lifetimes
(especially with respect to interface refcounting), TBitmap Pixelformat & co,
LCL event order, my pet peeve small type memory layout...
I get why most of them are/must be different, it's just that code compiles, but
stops working. That's kinda the opposite of what the technical definition of
"source-code compatible" means.


Really? Where did you find this definition ?

If your code relies on implementation details, it won't always work obviously.

But if you spot differences in behaviour, you can notify the devs. There are
then 2 options:
- They try to fix the behaviour.
- They explain why it works differently.

And that's all there is to say about it.

Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Sven Barth via Lazarus]

Am 19.02.2018 10:29 schrieb "Martok via Lazarus" <
lazarus@lists.lazarus-ide.org>:

> But source code written for Delphi must compile in FPC.
Should it also do something *similar*?


As long as the code does not rely on undocumented behavior, yes.

Regards,
Sven
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

Am 19.02.2018 um 00:18 schrieb Michael Van Canneyt via Lazarus:
> Why is it obviously not true ? It's obviously not true that it is compatible
> at the binary level. FPC does not produce the same binary code
I'm more talking about the macroscopic perspective. Of course the binary code
may be different, but does it have the same concept of what a specific block of
source "means"?

Or, put differently,
> But source code written for Delphi must compile in FPC.
Should it also do something *similar*?

Just from the things that come up at least twice a year in the time since I
started actively following the lists... tempvar allocation and lifetimes
(especially with respect to interface refcounting), TBitmap Pixelformat & co,
LCL event order, my pet peeve small type memory layout...
I get why most of them are/must be different, it's just that code compiles, but
stops working. That's kinda the opposite of what the technical definition of
"source-code compatible" means.

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Michael Van Canneyt via Lazarus]

On Sun, 18 Feb 2018, Martok via Lazarus wrote:


Am 18.02.2018 um 20:39 schrieb Michael Van Canneyt via Lazarus:

It's already fixed in SVN :)

FYI:
Line 121 contains a double http://
Line 234 is missing a "y" on "necessar_y_".


Also, while we're apparently in the off-topic section of this thread, a thought:
"""
fpc is designed to be, as much as possible, language and source-level compatible
with ISO pascal, Mac Pascal, Turbo Pascal 7.0 and most (if not all) versions of
Delphi.
"""
I wonder if you shouldn't leave out the words "source-level compatible", since
that is obviously not true. That phrasing implies the same code will do the same
thing (if it compiles), but with the amount of intentional differences between
fpc and "undocumented internals" of Borland's products that keep popping up, it
might be less surprising to people looking to write portable code if the claim
wasn't made in the first place. Same goes for LCL, really.


Why is it obviously not true ? It's obviously not true that it is compatible
at the binary level. FPC does not produce the same binary code, nor can you
use Delphi units.

But source code written for Delphi must compile in FPC. That is why I put
the sentence there. (in Delphi mode, obviously)

Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Giuliano Colla via Lazarus]

Il 18/02/2018 19:06, Graeme Geldenhuys via Lazarus ha scritto:

Are there any defined tests or test projects that can confirm 
LCL-Win32 is compatible with Delphi's VCL? I'm talking about events, 
order of events firing.


I hope that nobody will spend time which could be used for constructive 
purpose to verify Lazarus compliance to *undocumented* Delphi features, 
subject to change from one release to the next.


Giuliano

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Giuliano Colla via Lazarus]

Il 18/02/2018 19:42, Ondrej Pokorny via Lazarus ha scritto:


Do you mean TForm.OnPaint?



Yes, sorry for the typo.

Giuliano
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

Am 18.02.2018 um 20:39 schrieb Michael Van Canneyt via Lazarus:
> It's already fixed in SVN :)
FYI:
Line 121 contains a double http://
Line 234 is missing a "y" on "necessar_y_".


Also, while we're apparently in the off-topic section of this thread, a thought:
"""
fpc is designed to be, as much as possible, language and source-level compatible
with ISO pascal, Mac Pascal, Turbo Pascal 7.0 and most (if not all) versions of
Delphi.
"""
I wonder if you shouldn't leave out the words "source-level compatible", since
that is obviously not true. That phrasing implies the same code will do the same
thing (if it compiles), but with the amount of intentional differences between
fpc and "undocumented internals" of Borland's products that keep popping up, it
might be less surprising to people looking to write portable code if the claim
wasn't made in the first place. Same goes for LCL, really.

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Ondrej Pokorny via Lazarus]

On 18.02.2018 20:39, Michael Van Canneyt via Lazarus wrote:

On Sun, 18 Feb 2018, Ondrej Pokorny via Lazarus wrote:

The FPC team just forgot to update an outdated page.


It's already fixed in SVN :)


I expected Graeme to send a patch and help a little bit but you were 
obviously eager to fix it :)


Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Michael Van Canneyt via Lazarus]

On Sun, 18 Feb 2018, Ondrej Pokorny via Lazarus wrote:


On 18.02.2018 19:48, Graeme Geldenhuys via Lazarus wrote:
I understood that, I just wasn't sure if that was a "FPC goal" like 
the statement mentioned the D7 goal. I assumed any features post D7 
was just a bonus - thanks to development contributions.


Anyway, my original message was more targeted at Lazarus than at FPC. 
At least the FPC team mentioned some Delphi version (albeit outdated) 
they aspire to mimic. The Lazarus team don't mention anything - which 
I consider worse and raises uncertainty.


LOL, what uncertainty does it raise? By not mentioning a specific Delphi 
version we mean that Lazarus aims to mimic all Delphi features; that 
means always the latest version - a goal FPC aims as well.


The FPC team just forgot to update an outdated page.


It's already fixed in SVN :)

Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Ondrej Pokorny via Lazarus]

On 18.02.2018 19:06, Graeme Geldenhuys via Lazarus wrote:

On 2018-02-18 10:09, Ondrej Pokorny via Lazarus wrote:

Yes, it does. It is Delphi.


1) Not everybody owns a copy of Delphi to compare. Since when is it a 
good idea to have a Open Source project rely on a Commercial product.


Come on, AFAIK FPC and Lazarus have aimed to be Delphi compatible from 
the very beginning. You are much longer a member of the Lazarus 
community than I am, so you should know better. What do you want to say 
with this point?


Or am I somehow absolutely wrong and FPC/Lazarus are so close to Delphi 
by accident?


2) FPC seems to target Delphi 7 compatibility - but considering how 
old Delphi 7 is, that seems to be a ridiculous goal. 


:D OK, MvC and Florian already commented on this. I really don't 
understand why there is so much false/misleading information in this 
thread from you.



What Delphi version does the Lazarus project try to mimic?


The latest.

3) Does that mean LCL-Win32 being the closest to Delphi ie: a 
wrapper around the native Win32 controls. Does that mean LCL-Win32 is 
the reference implementation for all other LCL widgetsets?


Yes - in a loose way. There are Gtk2 and Qt specific properties in the 
LCL as well. See the Restricted tab in object inspector.


4) Continuing with option (3). Are there any defined tests or test 
projects that can confirm LCL-Win32 is compatible with Delphi's VCL? 
I'm talking about events, order of events firing. And then also 
components and properties of said components.


I am not aware of any (which doesn't mean they don't exist).

Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Florian Klämpfl via Lazarus]

Am 18.02.2018 um 19:48 schrieb Graeme Geldenhuys via Lazarus:
> On 2018-02-18 18:34, Michael Van Canneyt via Lazarus wrote:
>> That said, a small look at the language guide will of course convince even
>> the most malicious person that we also aim to be compatible - at the 
>> language level - with recent
>> Delphis...
> 
> 
> I understood that, I just wasn't sure if that was a "FPC goal" like the 
> statement mentioned the D7

The FPC goal is an open source pascal compiler, the supported language flavors 
depend on contributors.

> goal. I assumed any features post D7 was just a bonus - thanks to development 
> contributions.

This applies to every feature, even D7 features.
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Graeme Geldenhuys via Lazarus]

On 2018-02-18 18:34, Michael Van Canneyt via Lazarus wrote:

That said, a small look at the language guide will of course convince even
the most malicious person that we also aim to be compatible - at the 
language level - with recent Delphis...



I understood that, I just wasn't sure if that was a "FPC goal" like the 
statement mentioned the D7 goal. I assumed any features post D7 was just 
a bonus - thanks to development contributions.


Anyway, my original message was more targeted at Lazarus than at FPC. At 
least the FPC team mentioned some Delphi version (albeit outdated) they 
aspire to mimic. The Lazarus team don't mention anything - which I 
consider worse and raises uncertainty.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Ondrej Pokorny via Lazarus]

On 18.02.2018 17:19, Giuliano Colla wrote:

Il 18/02/2018 11:54, Ondrej Pokorny ha scritto:


What events are generated?


onFormPaint


Do you mean TForm.OnPaint?

---

No, no, no, no. Setting MyLabel.Color and any other visual property does 
NOT fire any paint event/method/whatever - neither in Delphi nor in 
Lazarus. Instead a repaint is requested with Invalidate/InvalidateRect 
that is then handled when the WM_PAINT message is received.


I really don't know where you got this information from. Or did I 
misunderstand you?


Ondrej

---

PS: A test project:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, 
System.Classes, Vcl.Graphics,

  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TForm1 = class(TForm)
    Label1: TLabel;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure FormPaint(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  Writeln('1');
  Label1.Color := clRed;
  Writeln('2');
  Label1.Color := clGreen;
  Writeln('3');
end;

procedure TForm1.FormPaint(Sender: TObject);
begin
  Caption := IntToStr(StrToIntDef(Caption, 0)+1);
  Writeln('paint');
end;

end.



object Form1: TForm1
  Left = 0
  Top = 0
  Caption = 'Form1'
  ClientHeight = 561
  ClientWidth = 391
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'Tahoma'
  Font.Style = []
  OldCreateOrder = False
  OnPaint = FormPaint
  PixelsPerInch = 96
  TextHeight = 13
  object Label1: TLabel
    Left = 80
    Top = 112
    Width = 31
    Height = 13
    Caption = 'Label1'
  end
  object Button1: TButton
    Left = 80
    Top = 155
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
    OnClick = Button1Click
  end
end
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Michael Van Canneyt via Lazarus]

On Sun, 18 Feb 2018, Florian Klämpfl via Lazarus wrote:


Am 18.02.2018 um 19:18 schrieb Graeme Geldenhuys via Lazarus:

On 2018-02-18 18:14, Graeme Geldenhuys via Lazarus wrote:

On 2018-02-18 18:10, Florian Klämpfl via Lazarus wrote:

What makes you think so?


Michael van Canneyt.



And quoting the official FPC documentation from the Free Pascal website:

"Free Pascal is designed to be, as much as possible, source compatible with 
Turbo Pascal 7.0 and
Delphi 7 (although this goal is not yet attained), ..."


Does it exclude other versions? No. This list also does not mention ISO or 
ObjFPC, so it is clear,
the two mentioned versions are only examples. Besides this, if you followed fpc 
development, you
should quickly realize that this page is simply outdated: no word on aarch64 
which is supported for
years as well as jvm and m68k, iOS is not mentioned. You should know also that 
FPC contains a lot of
stuff of newer delphis starting with advanced records, type helpers etc. which 
is for sure not D7.


I will update this page, it is indeed in dire need of a review.

That said, a small look at the language guide will of course convince even
the most malicious person that we also aim to be compatible - at the language 
level - with recent Delphis...


Michael.-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Florian Klämpfl via Lazarus]

Am 18.02.2018 um 19:18 schrieb Graeme Geldenhuys via Lazarus:
> On 2018-02-18 18:14, Graeme Geldenhuys via Lazarus wrote:
>> On 2018-02-18 18:10, Florian Klämpfl via Lazarus wrote:
>>> What makes you think so?
>>
>> Michael van Canneyt.
> 
> 
> And quoting the official FPC documentation from the Free Pascal website:
> 
> "Free Pascal is designed to be, as much as possible, source compatible with 
> Turbo Pascal 7.0 and
> Delphi 7 (although this goal is not yet attained), ..."

Does it exclude other versions? No. This list also does not mention ISO or 
ObjFPC, so it is clear,
the two mentioned versions are only examples. Besides this, if you followed fpc 
development, you
should quickly realize that this page is simply outdated: no word on aarch64 
which is supported for
years as well as jvm and m68k, iOS is not mentioned. You should know also that 
FPC contains a lot of
stuff of newer delphis starting with advanced records, type helpers etc. which 
is for sure not D7.

> 
> 
> https://www.freepascal.org/docs-html/current/user/userse2.html

-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Graeme Geldenhuys via Lazarus]

On 2018-02-18 18:06, Graeme Geldenhuys via Lazarus wrote:


1) Not everybody owns a copy of Delphi to compare. Since when is it a 
good idea to have a Open Source project rely on a Commercial product.


By that I also mean forcing people to own a copy of Windows and a copy 
of Delphi just to see if my Linux or FreeBSD Lazarus LCL-GTK2 or LCL-QT4 
is working as per the reference implementation. Forcing such 
requirements is ludicrous.


I personally haven't owned a copy of Windows since probably Windows 98 
which came with a very old laptop of mine. I believe neither FPC nor 
Lazarus support pre-Windows2000 any more.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Florian Klämpfl via Lazarus]

Am 18.02.2018 um 19:06 schrieb Graeme Geldenhuys via Lazarus:
> 
> 2) FPC seems to target Delphi 7 compatibility - 

What makes you think so?
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Ondrej Pokorny via Lazarus]

On 18.02.2018 19:08, Graeme Geldenhuys via Lazarus wrote:

On 2018-02-18 10:44, Giuliano Colla via Lazarus wrote:

To achieve the Delphi behavior in Lazarus I should code:

MyLabel.Color := clRed;
Application:ProcessMessages;
MyLabel.Color := clGreen;


If that's true


No, it is not true.

Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Graeme Geldenhuys via Lazarus]

On 2018-02-18 10:44, Giuliano Colla via Lazarus wrote:

To achieve the Delphi behavior in Lazarus I should code:

MyLabel.Color := clRed;
Application:ProcessMessages;
MyLabel.Color := clGreen;


If that's true, then the above is not Delphi compatible, and thus LCL is 
back to square one, of simply not being compatible with anything.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Graeme Geldenhuys via Lazarus]

On 2018-02-18 10:09, Ondrej Pokorny via Lazarus wrote:

Yes, it does. It is Delphi.


1) Not everybody owns a copy of Delphi to compare. Since when is it a 
good idea to have a Open Source project rely on a Commercial product.


2) FPC seems to target Delphi 7 compatibility - but considering how old 
Delphi 7 is, that seems to be a ridiculous goal. What Delphi version 
does the Lazarus project try to mimic?


3) Does that mean LCL-Win32 being the closest to Delphi ie: a 
wrapper around the native Win32 controls. Does that mean LCL-Win32 is 
the reference implementation for all other LCL widgetsets?


4) Continuing with option (3). Are there any defined tests or test 
projects that can confirm LCL-Win32 is compatible with Delphi's VCL? I'm 
talking about events, order of events firing. And then also components 
and properties of said components.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Giuliano Colla via Lazarus]

Il 18/02/2018 11:54, Ondrej Pokorny ha scritto:


What events are generated?


onFormPaint

Giuliano
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[José Mejuto via Lazarus]

El 18/02/2018 a las 0:52, Graeme Geldenhuys via Lazarus escribió:

On 2018-02-17 16:59, Gabor Boros via Lazarus wrote:
to answer your question I'm hoping that effort translates well to 
LCL-fpGUI too.


Hello,

I was talking about LCL-fpGUI with reation to other LCL based platforms. 
As I do not have a Delphi to verify I'm trying to mimic the win32 
platform (easy for me).


Anyway I'm not fixing event orders now, there are a lot fo things to do 
before ;-)


--

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Ondrej Pokorny via Lazarus]

On 18.02.2018 11:44, Giuliano Colla wrote:

Il 18/02/2018 11:09, Ondrej Pokorny via Lazarus ha scritto:


On 18.02.2018 0:59, Graeme Geldenhuys via Lazarus wrote:

Now comes the BIG question... Does LCL have a reference implementation?


Yes, it does. It is Delphi.



That's not true, as far as events triggering is concerned.
Delphi implementation is to fire each visual change when requested.
LCL implementation is to queue all visual changes and to fire all of 
them at the end. This provides better efficiency but completely 
disrupts the order in which events are fired.
Those lines of code generate two events on Delphi, and just one event 
on LCL:


MyLabel.Color := clRed;
MyLabel.Color := clGreen;


What events are generated?

Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Giuliano Colla via Lazarus]

Il 18/02/2018 11:09, Ondrej Pokorny via Lazarus ha scritto:


On 18.02.2018 0:59, Graeme Geldenhuys via Lazarus wrote:

Now comes the BIG question... Does LCL have a reference implementation?


Yes, it does. It is Delphi.



That's not true, as far as events triggering is concerned.
Delphi implementation is to fire each visual change when requested.
LCL implementation is to queue all visual changes and to fire all of 
them at the end. This provides better efficiency but completely disrupts 
the order in which events are fired.
Those lines of code generate two events on Delphi, and just one event on 
LCL:


MyLabel.Color := clRed;
MyLabel.Color := clGreen;

To achieve the Delphi behavior in Lazarus I should code:

MyLabel.Color := clRed;
Application:ProcessMessages;
MyLabel.Color := clGreen;


Giuliano

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Giuliano Colla via Lazarus]

Il 18/02/2018 00:59, Graeme Geldenhuys via Lazarus ha scritto:

Now comes the BIG question... Does LCL have a reference 
implementation? Which LCL widgetset gives the correct behaviour and 
feature list, that the other LCL widgetsets need to follow or mimic?


IMHO that's impossible to achieve.
Design is the art of compromise. When you request feature A and feature 
B which are mutually exclusive, you must decide which one is most 
important and drop the other.
Lazarus since the beginning has chosen (wrongly, IMO, but that's another 
matter) that the basic feature is *native* look and feel, by making LCL 
delegate as much as possible to the underlying widgetset. This is 
incompatible both with *consistent* look and feel, and with *consistent* 
behaviour.


Giuliano


--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Ondrej Pokorny via Lazarus]

On 18.02.2018 0:59, Graeme Geldenhuys via Lazarus wrote:

Now comes the BIG question... Does LCL have a reference implementation?


Yes, it does. It is Delphi.

Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Graeme Geldenhuys via Lazarus]

On 2018-02-17 18:37, José Mejuto via Lazarus wrote:

Is that nightmare exists with LCL-fpGUI also?


Probably in LCL-fpGUI the order is not the same


Now comes the BIG question... Does LCL have a reference implementation? 
Which LCL widgetset gives the correct behaviour and feature list, that 
the other LCL widgetsets need to follow or mimic?


Until that is answered, I guess it is every LCL widgetset for themselves 
and the inconsistencies in LCL will continue. And the burden falls on 
the application developer to try and fix the mess (via workarounds) - 
per application.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Graeme Geldenhuys via Lazarus]

On 2018-02-17 16:59, Gabor Boros via Lazarus wrote:

Is that nightmare exists with LCL-fpGUI also?


I can't speak much for LCL-fpGUI, but in "pure fpGUI" I spent probably a 
year of testing and development making sure the same events fire in the 
same order under all fpGUI supported platforms. I remember implementing 
numerous tests one after the other for every widget in the toolkit. So 
to answer your question I'm hoping that effort translates well to 
LCL-fpGUI too.


For pure fpGUI it took a lot of effort to get there, but the end result 
was well worth the effort. Resulting in very consistent behaviour across 
all platforms. What a developer would expect from a GUI toolkit.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[José Mejuto via Lazarus]

El 17/02/2018 a las 17:59, Gabor Boros via Lazarus escribió:

2018. 02. 17. 17:26 keltezéssel, Graeme Geldenhuys via Lazarus írta:
event orders and LCL was a nightmare - to the point that we moved to a 
completely different solution/toolkit.

Is that nightmare exists with LCL-fpGUI also?
Gabor


Hello,

Probably in LCL-fpGUI the order is not the same or even some events are 
not fired at all. In pure fpGUI apps I'm not sure about the consistence 
in the order of events/messages.


--

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Gabor Boros via Lazarus]

2018. 02. 17. 17:26 keltezéssel, Graeme Geldenhuys via Lazarus írta:
At the time (circa 2006) our 
application relied heavily on specific event orders and LCL was a 
nightmare - to the point that we moved to a completely different 
solution/toolkit.



Is that nightmare exists with LCL-fpGUI also?

Gabor
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Graeme Geldenhuys via Lazarus]

On 2018-02-16 17:40, Gabor Boros via Lazarus wrote:
I want to know when a form maximized, restored or moved. But completely 
lost between form's events.


I reported the LCL problem of inconsistent events and order of events 
between LCL widgetsets (at the time I compared LCL-QT3, LCL-Win32 and 
LCL-GTK2) some 12 years ago. From your email, it unfortunately seems 
nothing has changed in that regards. I guess you'll just have to live 
with it and do lots of testing in your own applications - and devise 
your own workarounds with {$IFDEF } etc code or field 
variables FInSomeEventFired: boolean etc. At the time (circa 2006) our 
application relied heavily on specific event orders and LCL was a 
nightmare - to the point that we moved to a completely different 
solution/toolkit.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Form events firing order and count

[Wolf via Lazarus]

When I was in the same situation, I modified each procedure / function 
to read


procedure xxx

begin

{first line} write('procedure xx opened');

...

{last line} writeln('procedure xxx closed');

end;

This produced on the console an easy trace of who called whom, and how 
they were stacked.


Wolf


On 17/02/2018 06:40, Gabor Boros via Lazarus wrote:

Hi All,

I want to know when a form maximized, restored or moved. But 
completely lost between form's events. See below what I got with the 
attached example project. For example 1 WindowPosChanged at 
application start with Linux-Qt and 3 with Windows, with Linux-Qt form 
maximize and restore give same result but with Windows the result 
different for maximize and restore, etc.


*Linux-Qt*

*Application start*
Resize
ChangeBounds
WindowPosChanged
Move

*Form maximize*
WindowStateChange
Move
ChangeBounds
WindowPosChanged
Resize

*Form restore*
WindowStateChange
Move
ChangeBounds
WindowPosChanged
Resize

*After form move*
Move

*Windows*

*Application start*
Resize
ChangeBounds
WindowPosChanged
Move
WindowPosChanged
WindowPosChanged

*Form maximize*
Move
ChangeBounds
WindowPosChanged
Resize
WindowStateChange
WindowPosChanged

*Form restore*
ChangeBounds
WindowPosChanged
Resize
WindowStateChange
WindowPosChanged

*Meanwhile form move*
Move
WindowPosChanged
Move
WindowPosChanged
.
.
.
Move
WindowPosChanged

Gabor




-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Form events firing order and count

[Gabor Boros via Lazarus]

Hi All,

I want to know when a form maximized, restored or moved. But completely 
lost between form's events. See below what I got with the attached 
example project. For example 1 WindowPosChanged at application start 
with Linux-Qt and 3 with Windows, with Linux-Qt form maximize and 
restore give same result but with Windows the result different for 
maximize and restore, etc.


*Linux-Qt*

*Application start*
Resize
ChangeBounds
WindowPosChanged
Move

*Form maximize*
WindowStateChange
Move
ChangeBounds
WindowPosChanged
Resize

*Form restore*
WindowStateChange
Move
ChangeBounds
WindowPosChanged
Resize

*After form move*
Move

*Windows*

*Application start*
Resize
ChangeBounds
WindowPosChanged
Move
WindowPosChanged
WindowPosChanged

*Form maximize*
Move
ChangeBounds
WindowPosChanged
Resize
WindowStateChange
WindowPosChanged

*Form restore*
ChangeBounds
WindowPosChanged
Resize
WindowStateChange
WindowPosChanged

*Meanwhile form move*
Move
WindowPosChanged
Move
WindowPosChanged
.
.
.
Move
WindowPosChanged

Gabor


FormEvents.tar.gz
Description: GNU Zip compressed data
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus