View Issue Details

IDProjectCategoryView StatusLast Update
0032335LazarusLCLpublic2017-11-10 09:44
ReporterStephanie Assigned ToOndrej Pokorny  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionwon't fix 
PlatformAMD64OSLinux 
Product Version1.8RC3 
Summary0032335: TDateEdit: SelectNext doesn't work
DescriptionHello, it I use SelectNext in order to put the focus on the next control it doesn't work, the same if I use PerformTab, only ActiveControl works:

procedure TfrmPrimanota.DateEdit1KeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
begin
  if (Key = 39{KeyArrowRight}) or (Key = 13{KeyInvio}) then begin
    //Self.SelectNext (DateEdit1, True, True); //Doesn't work
    //DateEdit1.PerformTab(True); //Doesn't work
    Self.ActiveControl := DateEdit2; //Works correctly
    Key := 0;
  end;
end;

With the other controls (TEdit, TDbEdit, etc.) SelectNext works correctly, only with TDateEdit there is the problem.

Sorry for my bad english.

Best regards,

Stephanie
TagsNo tags attached.
Fixed in Revision
LazTarget-
WidgetsetGTK 2
Attached Files

Relationships

related to 0032455 closedOndrej Pokorny AV on open form in revision 55890 
related to 0032533 closedMichl TDateEdit/TTimeEdit controls break the tab order 
related to 0032536 resolvedJuha Manninen TFileNameEdit eats Focus. 
related to 0032601 resolvedMichl TSpinEditEx Focus on Tab Click doesn't work 

Activities

Zeljan Rikalo

2017-08-31 09:58

developer   ~0102527

Please attach example project.

Stephanie

2017-08-31 17:14

reporter  

DateEditSample.zip (128,323 bytes)

jamie philbrook

2017-08-31 19:04

reporter   ~0102541

I just put three TdateEdits and one TspinEdit on a form and check the
Keypreview of form.

 in the KeyDown I did this.
procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState
  );
begin
  If key = VK_RIGHT Then SelectNext(ActiveControl,True, True);
  If Key= VK_LEFT Then SelectNext(ACtiveControl,False, True);
end;

 The TDateEdit Controls will not go backwards but the TspinEdit will.
So maybe there are multiple issues here?
This was done on 1.6.4 32 bits windows

Bart Broersma

2017-08-31 23:57

developer   ~0102546

For me this works with trunk.
Tried TEditButton, TDateEdit and TFilenameEdit.
Lazarus 1.9.0 r55723 FPC 3.0.4 x86_64-linux-gtk2

Stephanie

2017-09-01 00:17

reporter   ~0102547

Thanks, it Will be ok with RC5 or stable 1.8.0? Is there a patch to apply?

Michl

2017-09-20 23:03

developer   ~0102958

There were two issues:
1. The property TabStop was reintroduced, so the TWinControl(TDateEdit) returned always False.
2. The method TWincontrol.GetTabOrderList returned all child controls. So the next control for TDateEdit was it's child TEbEdit and it focused itself.

I fixed this issues in Trunk revision 55890.


In your example as a workaround, you can use (before revision 55890):

...
  if (MyKey in [13{KeyInvio}, 39{KeyArrowRight}]) then begin
    MyForm.SelectNext(MySender as TWinControl, True, False); <-- last property False

Ondrej Pokorny

2017-11-09 23:42

developer   ~0103980

Last edited: 2017-11-09 23:46

View 3 revisions

1. The TabStop property was reintroduced for a reason (see all various regressions). The Color property is reintroduced as well.

2. SelectNext selects the next child control. Because TDateEdit is a container the next child control of TDateEdit is the editor inside => your demo works fine. You have to change your code and not the LCL.

The correct code for your scenario is:

Screen.ActiveForm.SelectNext (Screen.ActiveControl, True, True);

(The Tab handling mess in group edit has to be reverted.)

Ondrej Pokorny

2017-11-09 23:51

developer   ~0103981

> so the TWinControl(TDateEdit) returned always False.

This is exactly what you always want for a container control (e.g. panel, groupbox, scrollbox etc.).

Ondrej Pokorny

2017-11-10 09:44

developer   ~0103985

This behavior is a consequence of the fact that TDateEdit is a container control (like a panel with an edit) and the Sender parameter in KeyDown is not the focused control.

Trying to fix this caused (and will always cause) a never ending story of regressions.

You got a valid workaround in 0032335:0103980.

Issue History

Date Modified Username Field Change
2017-08-26 11:34 Stephanie New Issue
2017-08-31 09:58 Zeljan Rikalo Note Added: 0102527
2017-08-31 17:14 Stephanie File Added: DateEditSample.zip
2017-08-31 19:04 jamie philbrook Note Added: 0102541
2017-08-31 23:57 Bart Broersma Note Added: 0102546
2017-09-01 00:17 Stephanie Note Added: 0102547
2017-09-20 23:03 Michl Fixed in Revision => 55890
2017-09-20 23:03 Michl LazTarget => 1.8
2017-09-20 23:03 Michl Note Added: 0102958
2017-09-20 23:03 Michl Status new => resolved
2017-09-20 23:03 Michl Fixed in Version => 1.9 (SVN)
2017-09-20 23:03 Michl Resolution open => fixed
2017-09-20 23:03 Michl Assigned To => Michl
2017-09-20 23:03 Michl Target Version => 1.8
2017-09-22 08:24 Michl Relationship added related to 0032455
2017-10-11 22:03 Michl Relationship added related to 0032533
2017-10-12 11:06 Juha Manninen Relationship added related to 0032536
2017-10-23 11:22 Michl Relationship added related to 0032601
2017-11-09 23:42 Ondrej Pokorny Assigned To Michl => Ondrej Pokorny
2017-11-09 23:42 Ondrej Pokorny Note Added: 0103980
2017-11-09 23:42 Ondrej Pokorny Status resolved => assigned
2017-11-09 23:42 Ondrej Pokorny Resolution fixed => reopened
2017-11-09 23:43 Ondrej Pokorny Note Edited: 0103980 View Revisions
2017-11-09 23:46 Ondrej Pokorny Note Edited: 0103980 View Revisions
2017-11-09 23:51 Ondrej Pokorny Note Added: 0103981
2017-11-10 09:44 Ondrej Pokorny Fixed in Revision 55890 =>
2017-11-10 09:44 Ondrej Pokorny LazTarget 1.8 => -
2017-11-10 09:44 Ondrej Pokorny Note Added: 0103985
2017-11-10 09:44 Ondrej Pokorny Status assigned => resolved
2017-11-10 09:44 Ondrej Pokorny Fixed in Version 1.9 (SVN) =>
2017-11-10 09:44 Ondrej Pokorny Resolution reopened => won't fix
2017-11-10 09:44 Ondrej Pokorny Target Version 1.8 =>