Re: [Lazarus] Form events firing order and count

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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] Compilation aborted!

2018-02-18 Thread Donald Ziesig via Lazarus

On 02/18/2018 04:02 AM, Mattias Gaertner via Lazarus wrote:

On Sat, 17 Feb 2018 22:35:17 -0500
Donald Ziesig via Lazarus  wrote:


[...]
Isolated it to FPC.  Ran fpc from terminal without IDE.  Got same error
(AV).  It is getting late here. I will look at this in the morning.

Maybe you got messed up ppu files, or you messed up unit paths.

Mattias


I found the problem!  It is definitely a compiler bug (compiler did NOT 
report the actual error, all it did was throw an Access Violation).


Unfortunately, I had changed one more line than I remembered during the 
last edit before the failure.


That line was (in the type(s) declaration:

    TAMBytes = array[0..1] of Byte;

I changed it to:

  TAMBytes = array[0..High(Integer)] of Byte;

Type TAMBytes was used as the return type is several functions. When I 
commented out ALL of the code that used TAMBytes, the error went away.  
Since TAMBytes was the only consistent item in that code, I checked its 
declaration and remembered the other :-[ change I made. Reverted that to 
the original version and the compilation succeeded.  Finally changed it to:


  TAMBytes = array[0..32767] of Byte;

This also compiled successfully, and was big enough that it will handle 
much bigger arrays than I expected to use.


I will create a simplified test case and submit a bug report to Free Pascal.

Thanks for putting up with my earlier complaints.

Don Ziesig


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


Re: [Lazarus] OI / App crash - components with published interfaces

2018-02-18 Thread Andreas Frieß via Lazarus
THX for the information Martin, i have changed the line and it looks 
good. Very good.


This code is a prototype for me to inhibt unwanted Ref Counter changes.


Am 18.02.2018 um 16:32 schrieb Martin Schreiber via Lazarus:

pointer(FObjectHasInterface):= nil;


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


Re: [Lazarus] ghost selector in form editor

2018-02-18 Thread Bart via Lazarus
On Sun, Feb 18, 2018 at 1:17 AM, Juha Manninen via Lazarus
 wrote:

> There is an oldish report:
>  https://bugs.freepascal.org/view.php?id=23741

Or even older:
https://bugs.freepascal.org/view.php?id=13062
(But that was on WinMe)

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


Re: [Lazarus] Form events firing order and count

2018-02-18 Thread 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] OI / App crash - components with published interfaces

2018-02-18 Thread Martin Schreiber via Lazarus
On Sunday 18 February 2018 13:16:36 Andreas Friec39f via Lazarus wrote:
> Now i have inserted code in the TIntfComp to remove the link to the
> interface
>
> 
>
> destructor TIntfComp.Destroy;
> begin
>    FObjectHasInterface := nil;  // <<-- Crahe here now
>    inherited Destroy;
> end;
> 
>
> And now i it crash explicitly  at the line wher i try to 'unlink'. And
> the Callstack from Lazarus give me some information. The setting to nil,
> call fpc_intf_assign and  call IUnknown(D)._Release. But this is
> absolutly unwated (and unexpected) for me here.
>
I did not read the whole thread.
If you want to set a COM interface pointer to nil without calling _release() 
use 
"
 pointer(FObjectHasInterface):= nil;
"
It is very difficult or even impossible in Delphi and FPC to reliable mix 
reference counted COM interfaces with TComponent/TObject life cycle 
management. If you need interfaces without reference counting use CORBA 
interfaces.
Never use COM-interface variables if there are TObject.Destroy() calls. It is 
an undefined "implementation detail" when the interface variable goes out of 
scope, there is a risk that it goes out of scope and _release() will be 
called after the according object has been destroyed by a TObject.Destroy() 
call.

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


Re: [Lazarus] ghost selector in form editor

2018-02-18 Thread Luca Olivetti via Lazarus

El 18/02/18 a les 10:31, Luca Olivetti via Lazarus ha escrit:


The plot thickens:

while the ghost selector of a label diverges from the real one, the 
ghost selector of other controls moves in sync:



https://www.youtube.com/watch?v=wTAKaYIM8_U


Meanwhile, I compiled the ide with qt5 and it doesn't show the problem, 
while with gtk, see the link, ouch!. I only selected the "PLANTA 
OFICINES" label.


https://imgur.com/a/FSt5f

Under windows it would "only" show one ghost selector.

Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Form events firing order and count

2018-02-18 Thread 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] OI / App crash - components with published interfaces

2018-02-18 Thread Andreas Frieß via Lazarus
Now i have inserted code in the TIntfComp to remove the link to the 
interface




destructor TIntfComp.Destroy;
begin
  FObjectHasInterface := nil;  // <<-- Crahe here now
  inherited Destroy;
end;


And now i it crash explicitly  at the line wher i try to 'unlink'. And 
the Callstack from Lazarus give me some information. The setting to nil, 
call fpc_intf_assign and  call IUnknown(D)._Release. But this is 
absolutly unwated (and unexpected) for me here.


How can i release the link without calling  fpc_intf_assign. Or what is 
my mistake of understanding ?


Andreas

---

#0 fpc_intf_assign at :0
#1 DESTROY(0x3868750, 0x1) at intfcomp.pas:76
#2 CLASSES$_$TCOMPONENT_$__$$_DESTROYCOMPONENTS at :0
#3 CLASSES$_$TCOMPONENT_$__$$_DESTROY at :0
#4 ?? at :0
#5 DESTROY(0x3838d38, 0x0) at include\control.inc:5146
#6 DESTROY(0x3838d38, 0x0) at include\wincontrol.inc:6626
#7 DESTROY(0x3838d38, 0x0) at include\customcontrol.inc:40
#8 DESTROY(0x3838d38, 0x0) at include\scrollingwincontrol.inc:316
#9 DESTROY(0x3838d38, 0x1) at include\customform.inc:212
#10 SYSTEM$_$TOBJECT_$__$$_FREE at :0
#11 FREEUSEDOBJECTS(0x38648d8) at uoitest.pas:161
#12 BUFREECLICK(0x38648d8, 0x3865a58) at uoitest.pas:139
---


Am 17.02.2018 um 10:53 schrieb Andreas Frieß via Lazarus:
I have an appcrash when i use components with interfaces in the 
published part. See also Bug 32919. I have now simpilied the problem 
and isolated from Lazarus itself.


The component is on https://github.com/afriess/LazarusBug0032919 in 
OITestBasic, together with the testproject shown here.


Somethigs goes wrong , if call free for the Form ( SIGSEGV ). A 
sencond issue is, i did not see the value of the property 
ObjectHasInterface in the OI.  But i see the value if i click on the 
Combobox.


My Question:

Did i miss something in the definition of the Components ?

 definition components ---

type
  // define the Interface
  ITestInterface =  interface
  function OnlyDummy: integer;
    end;

  { TIntfComp }
  TIntfComp = class(TComponent)
  private
    FObjectHasInterface: ITestInterface;
    function GetObjectHasInterface: ITestInterface;
    procedure SetObjectHasInterface(AValue: ITestInterface);
  published
    property ObjectHasInterface: ITestInterface read 
GetObjectHasInterface write SetObjectHasInterface;

  end;

  { TCompHasIntf }
  TCompHasIntf = class(TComponent, ITestInterface)
  public
    function OnlyDummy: integer;
  end;

- test programm 

    DUT := TObjectInspectorDlg.Create(nil);
    DUT.Caption:= 'My ObjectInspector';

    // create the PropertyEditorHook (the interface to the properties)
    ThePropertyEditorHook:=TPropertyEditorHook.Create(DUT);
    DUT.PropertyEditorHook:=ThePropertyEditorHook;

    // Create components
    ATestForm :=  TForm.Create(nil);
    ATestForm.Name:= 'Main';

    ATestIntf := TIntfComp.Create(ATestForm);   // This componnets 
can hold a component with interface

    ATestIntf.Name := 'ATestIntf';
    ATestHasIntf := TCompHasIntf.Create(ATestForm); // This component 
has an Interface

    ATestHasIntf.Name:= 'ATestHasIntf';
    ATestIntf.ObjectHasInterface := ATestHasIntf;
    ATestIntf.GetParentComponent;
    ThePropertyEditorHook.LookupRoot:=ATestForm;

    PerList:=TPersistentSelectionList.Create;
    PerList.Add(ATestForm);
    DUT.Selection:=PerList;
    PerList.Free;

    DUT.Show;

...

  if DUT <> nil then begin
    ATestForm.Free;   // <- Appcrash
    FreeAndNil(DUT);
  end;
--- End --


-- Stack 

#0 fpc_intf_decr_ref at :0
#1 fpc_finalize at :0
#2 ?? at :0
#3 SYSTEM_$$_SETVARIANTMANAGER$TVARIANTMANAGER at :0
#4 ?? at :0
#5 DESTROY(0x3aa8868, 0x0) at include\control.inc:5146
#6 DESTROY(0x3aa8868, 0x0) at include\wincontrol.inc:6626
#7 DESTROY(0x3aa8868, 0x0) at include\customcontrol.inc:40
#8 DESTROY(0x3aa8868, 0x0) at include\scrollingwincontrol.inc:316
#9 DESTROY(0x3aa8868, 0x1) at include\customform.inc:212
#10 SYSTEM$_$TOBJECT_$__$$_FREE at :0
#11 FREEUSEDOBJECTS(0x3ad46f8) at uoitest.pas:161
#12 BUFREECLICK(0x3ad46f8, 0x3ad5878) at uoitest.pas:139
#13 CLICK(0x3ad5878) at include\control.inc:2929
#14 CLICK(0x3ad5878) at include\buttoncontrol.inc:55
#15 CLICK(0x3ad5878) at include\buttons.inc:169
#16 WMDEFAULTCLICKED(0x3ad5878, {MSG = 66567, WPARAM = 0, LPARAM = 0, 
RESULT = 0, WPARAMLO = 0, WPARAMHI = 0, WPARAMFILLER = {}, LPARAMLO = 
0, LPARAMHI = 0, LPARAMFILLER = {}, RESULTLO = 0, RESULTHI = 0, 
RESULTFILLER = {}}) at include\buttoncontrol.inc:21

#17 SYSTEM$_$TOBJECT_$__$$_DISPATCH$formal at :0
#18 ?? at :0
#19 VMT_$STDCTRLS_$$_TBUTTONCONTROL at :0
#20 VMT_$STDCTRLS_$$_TCUSTOMSTATICTEXT$indirect at :0
#21 STDCTRLS$_$TBUTTONCONTROL_$__$$_ISCHECKEDSTORED$$BOOLEAN at :0
#22 WNDPROC(0x3ad5878, {MSG = 66567, WPARAM = 0, LPARAM = 0, RESULT = 
0, WPARAMLO = 0, WPARAMHI = 

Re: [Lazarus] WARNING: TResourceCacheItem.IncreaseRefCount 1000 TFontHandleCache

2018-02-18 Thread Michael W. Vogel via Lazarus

Am 16.02.2018 um 22:16 schrieb Vojtěch Čihák via Lazarus:


Hi,

don't you know what does this output mean(in Console In/Output, not in 
Messages): WARNING: TResourceCacheItem.IncreaseRefCount 1000 
TFontHandleCache ?


Thanks,

V.



Please create a minimal example and report to mantis bugtracker.

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


Re: [Lazarus] Form events firing order and count

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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

2018-02-18 Thread 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] ghost selector in form editor

2018-02-18 Thread Luca Olivetti via Lazarus

El 18/02/18 a les 10:24, Luca Olivetti via Lazarus ha escrit:

El 18/02/18 a les 01:17, Juha Manninen via Lazarus ha escrit:

On Thu, Feb 15, 2018 at 10:10 AM, Luca Olivetti via Lazarus
 wrote:
I've been seeing this from time immemorial, probably since 
0.something, both
under windows and linux/gtk/qt (though under linux is much more 
frequent):


There is an oldish report:
  https://bugs.freepascal.org/view.php?id=23741
but I don't remember seeing this problem although I have used many
Linux distributions and few Windows versions, too.
What can make the difference?
Does it happen only with particular forms or with any form?


I don't know. I'm currently using kubuntu 17.10 and a windows 7 virtual 
machine, but I've seen it with windows xp and my previous linux 
distributions (older versions of kubuntu, mageia, mandriva).
In any case, I'm not sure the cause it's the same both on windows and 
linux: in linux it's enough to drop a label on a form, and when I move 
it the position of the ghost selector diverges from the real one


https://www.youtube.com/watch?v=ZteRShCdkDA

under windows I need a more complex form and the ghost selector moves in 
sync with the real one.

Notice also how the ghost selector of the string grid is just one point.

https://www.youtube.com/watch?v=EY92B46URZ8


The plot thickens:

while the ghost selector of a label diverges from the real one, the 
ghost selector of other controls moves in sync:



https://www.youtube.com/watch?v=wTAKaYIM8_U

Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] ghost selector in form editor

2018-02-18 Thread Luca Olivetti via Lazarus

El 18/02/18 a les 01:17, Juha Manninen via Lazarus ha escrit:

On Thu, Feb 15, 2018 at 10:10 AM, Luca Olivetti via Lazarus
 wrote:

I've been seeing this from time immemorial, probably since 0.something, both
under windows and linux/gtk/qt (though under linux is much more frequent):


There is an oldish report:
  https://bugs.freepascal.org/view.php?id=23741
but I don't remember seeing this problem although I have used many
Linux distributions and few Windows versions, too.
What can make the difference?
Does it happen only with particular forms or with any form?


I don't know. I'm currently using kubuntu 17.10 and a windows 7 virtual 
machine, but I've seen it with windows xp and my previous linux 
distributions (older versions of kubuntu, mageia, mandriva).
In any case, I'm not sure the cause it's the same both on windows and 
linux: in linux it's enough to drop a label on a form, and when I move 
it the position of the ghost selector diverges from the real one


https://www.youtube.com/watch?v=ZteRShCdkDA

under windows I need a more complex form and the ghost selector moves in 
sync with the real one.

Notice also how the ghost selector of the string grid is just one point.

https://www.youtube.com/watch?v=EY92B46URZ8

Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] ghost selector in form editor

2018-02-18 Thread Luca Olivetti via Lazarus

El 18/02/18 a les 02:41, Vojtěch Čihák via Lazarus ha escrit:

Hi,

I can simulate this on Qt in several ways:

1) select two components on different tabs of page control, one of them 
will be ghost


That I think it's a different issue (and, IIRC, I saw that too). In this 
case it's just a plain form.
As I said, I seen this for a long, long time. Much more often with linux 
than with windows.
E.g., see the attached screenshot (linux/gtk), I just created a new 
application and dropped a label on the form. That's all.




2) some components can be hidden behind other, it is caused by wrong 
Z-order, for example TSpeedButton behind enlarged non-transparent TLabel 
or TStaticText.


and probably other ways.

BTW, what control is that "Status no valido!" caption? Isn't it the case 
no.2?


It' just a label

Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Compilation aborted!

2018-02-18 Thread Mattias Gaertner via Lazarus
On Sat, 17 Feb 2018 22:35:17 -0500
Donald Ziesig via Lazarus  wrote:

>[...]
> Isolated it to FPC.  Ran fpc from terminal without IDE.  Got same error 
> (AV).  It is getting late here. I will look at this in the morning.

Maybe you got messed up ppu files, or you messed up unit paths.

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