View Issue Details

IDProjectCategoryView StatusLast Update
0026057LazarusLCLpublic2014-04-23 22:31
ReporterJoachim PaepkeAssigned ToBart Broersma 
Status closedResolutionfixed 
Platformi386OSLinuxOS Version3.2.0-4-686-pae
Product Version1.3 (SVN)Product Build44768 
Target VersionFixed in Version1.4 
Summary0026057: property OnKeyDown of TCustomEditButton not correct
DescriptionIn TCustomEditButon in section protected there is:

property OnKeyDown:TKeyEvent read FOnEditKeyDown write FOnEditKeyDown

Do this:

TMyEditButton = class(TCustomEditButton)
    property OnKeyDown;

This has no effect. You wont get the Event from the Edit because TCustomEdit is derived from TCustomControl and this from TWinControl. In TWinControl there is in section public already the same property which will not be overridden with this. I think the property should be already in public section when declared in TCustomEditButton in this way:

TCustomEditButton = class(TCustomControl)
  property OnKeyDown read FOnEditKeyDown write FOnEditKeyDown;

Then the behaviour would be as expected
TagsNo tags attached.
Fixed in Revisionr44796
WidgetsetGTK 2
Attached Files


Joachim Paepke

2014-04-23 11:17

reporter   ~0074532

By the way, it is suspicious that the compiler eats this happily without any warning about overriding or redeclaring an existing property. Anyway, an assignment to OnKeyDown goes through to TWinControl and is stored there in its private field FOnKeyDown an not as expected to TCustomEditButton.FOnEditKeyDown.
To avoid this the property should be redeclared as I suggested.
And more: There are other propertys in TCustomEditButton which seem to have the same problem

Bart Broersma

2014-04-23 13:45

developer   ~0074534

Did you even try assigning OnKeyDown for e.g. a TFileNameEdit (which is a derived class from TCustomEditButton and it does publish OnKeyDown like you did) either in OI or @runtime and see what happens?
For me this works as expected both @designtime and @runtime.

If this does not work for you please attach a compileable minimal testcase project (sources only), demonstrating the problem.

> By the way, it is suspicious that the compiler eats this happily without any
> warning about overriding or redeclaring an existing property.

This is by design.

Joachim Paepke

2014-04-23 14:59

reporter (127,522 bytes)

Joachim Paepke

2014-04-23 15:00

reporter   ~0074535

Here is the example. Please take a look at it and see what happens (not)

Bart Broersma

2014-04-23 17:46

developer (2,131 bytes)

Bart Broersma

2014-04-23 17:50

developer   ~0074540

Simpliefied your example (
Please run and test.

This is the output when I press Tab 3 times:

Sender is TEditButton, Name = "EditButton1, Parent = "Form1", Key = 0x0009
Sender is TXEditButton, Name = "X1, Parent = "Form1", Key = 0x0009
Sender is TXEditButton, Name = "X2, Parent = "Form1", Key = 0x0009

This is as expected and IMO how it should be.

OT: your source code had strange formatting...

Joachim Paepke

2014-04-23 18:13

reporter   ~0074541

You changed x1 from TCustomEditButton to tXEditButton. Sure then its working correct.
I wanted to show the following: Consider a situation You need a placeholder (TCustomEditButton) at a point You do not know what derived object would take the place at runtime (p.e. a custom editor in a stringgrid). After creating the new derived editor and assigning it to the placeholder it would not be possible to assign the event directly via the placeholder. It only will work when You explicitly typecast the palceholder: TXButton(PlaceHolder).OnKeyDown:= . . .
O.k. this is not hard to do, but as TCustomEditButton is a Edit I would assumed that assigning to the event works in all cases without typecast; esp. as the old TEditButton behaved like this.
I came to this because this behavour broke much of my old code. For the moment I insertet the typecast at the relevant palces so my work can go on.

Bart Broersma

2014-04-23 20:17

developer   ~0074542

procedure TForm1.FormCreate(Sender: TObject);
  x1: TCustomEditButton;
  x1.Top:=EditButton1.Top + EditButton1.Height + 10;
  x1.OnKeyDown:=@Edit1KeyDown; := 'X1';

Indeed this will not fire OnKeydown.
I have no idea why, I'll look into it.

Joachim Paepke

2014-04-23 20:38

reporter   ~0074543

The event OnKeyDown of TCustomEditButton does not override the same named event of the upper class (in this case the OnKeyDown of TWinControl). Thats also I was astonished not to get a warning by the compiler.
If You look at it with the debugger (where You can see also the private fields) You can see that the assignment ends up in TWinControl.FOnKeyDown and not in TCustomEdit.FOnEditKeyDown;
Thats why I suggested to override the property of TWinControl:
  property OnKeyDown read FOnEditKeyDown write FOnEditKeyDown;
At the moment You need the explicitly typecast that the correct OnKeyDown is taken by the compiler.

Bart Broersma

2014-04-23 21:07

developer   ~0074545

Fixed as proposed by making all OnXXX properties public in TCustomEditButton.
Thanks for reporting.
Please test and close if OK.

Joachim Paepke

2014-04-23 22:31

reporter   ~0074550

Is working. In fact You redeclared the events thus hiding the ones from upper objects instead of my suggestion in overriding the propertys. But nevertheless it is working.

Issue History

Date Modified Username Field Change
2014-04-22 20:47 Joachim Paepke New Issue
2014-04-23 07:21 Zeljan Rikalo Assigned To => Bart Broersma
2014-04-23 07:21 Zeljan Rikalo Status new => assigned
2014-04-23 11:17 Joachim Paepke Note Added: 0074532
2014-04-23 13:45 Bart Broersma LazTarget => -
2014-04-23 13:45 Bart Broersma Note Added: 0074534
2014-04-23 13:45 Bart Broersma Status assigned => feedback
2014-04-23 14:59 Joachim Paepke File Added:
2014-04-23 15:00 Joachim Paepke Note Added: 0074535
2014-04-23 15:00 Joachim Paepke Status feedback => assigned
2014-04-23 17:46 Bart Broersma File Added:
2014-04-23 17:50 Bart Broersma Note Added: 0074540
2014-04-23 17:50 Bart Broersma Status assigned => feedback
2014-04-23 18:13 Joachim Paepke Note Added: 0074541
2014-04-23 18:13 Joachim Paepke Status feedback => assigned
2014-04-23 20:17 Bart Broersma Note Added: 0074542
2014-04-23 20:38 Joachim Paepke Note Added: 0074543
2014-04-23 21:07 Bart Broersma Fixed in Revision => r44796
2014-04-23 21:07 Bart Broersma Note Added: 0074545
2014-04-23 21:07 Bart Broersma Status assigned => resolved
2014-04-23 21:07 Bart Broersma Fixed in Version => 1.4
2014-04-23 21:07 Bart Broersma Resolution open => fixed
2014-04-23 22:31 Joachim Paepke Note Added: 0074550
2014-04-23 22:31 Joachim Paepke Status resolved => closed