[Lazarus] Order of events: TEdit / TListBox

[kapibara via Lazarus]

Is this a bug?

Simple demo: TEdit and TListBox are on a form. The TEdit is used to
rename selected string in the ListBox. The code for renaming is in the
Exit event of the TEdit. When an item in the ListBox is selected, the
Edit.Exit should fire and copy the Edit.Text to the current item in the
ListBox. The OnSelectionChange then copies the name of the selected
ListBox item to the TEdit.

This only works if selecting the already selected item in the ListBox.
If instead another Item is selected, the Edit.Text is overwritten before
it is copied to the old ListBox item: the ListBox.OnSelectionChange
fires before Edit.Exit.

ListBox.OnSelectionChange fires *before* both ListBox.Click and
Edit.Exit. I would expect Click to fire before SelectionChange? And
Edit.Exit before ListBox.Click, which it does, but only if
OnSelectionChange doesn't fire at all.

Clicking an item in the ListBox that is already selected results in the
same event order as in Delphi: Edit.Exit -> ListBox.Click.

Lazarus trunk, GTK2 Linux

There is an attached project.

[kapibara via Lazarus]

Showing events.

[kapibara via Lazarus]

Some more findings. Under Windows, the Edit.Exit event fires before both
SelectionChange and OnClick no matter what item you select.
Plus under Windows, SelectionChange fires even though an item might
already be selected which it doesn't under Linux GTK2. Under both
environments, the Click event fires after SelectionChange..

[zeljko via Lazarus]

Post by kapibara via Lazarus
Some more findings. Under Windows, the Edit.Exit event fires before both
SelectionChange and OnClick no matter what item you select.

It's normal. If you click onto listbox (OnMouseDown of listbox
triggers), TEdit looses focus and triggers OnExit()

Post by kapibara via Lazarus
Plus under Windows, SelectionChange fires even though an item might
already be selected which it doesn't under Linux GTK2. Under both
environments, the Click event fires after SelectionChange..

OnClick() is passed after OnMouseDown() + OnMouseUp(), so it's normal.
When you press one item with mouse selection changes (click isn't
triggered yet), releasing mouse triggers MouseUp and Click().

zeljko

--

[kapibara via Lazarus]

This post might be inappropriate. Click to display it.

[zeljko via Lazarus]

Post by kapibara via Lazarus

Post by zeljko via Lazarus
It's normal. If you click onto listbox (OnMouseDown of listbox
triggers), TEdit looses focus and triggers OnExit()

Thanks for the reply.
Yes, on Windows, Lazarus and Delphi 7 behave the same. Except that
Lazarus Win platform: Edit.Exit always fires before ListBox.OnClick (and
OnSelectionChange), no matter if the ListBox item is selected or not.
Good. Though I would not expect SelectionChange to fired since there is
no change in selection?
Problem is with Lazarus Linux GTK2. Events behave the *opposite* to
1) SelectionChange does not fire when clicking an already selected item.
I might be wrong, but thats good I think and the windows implementation bad?
2) Edit.Exit fires BEFORE ListBox.OnClick if selecting and already
selected ListBox item. Good.
3) Edit.Exit fires AFTER ListBox.SelectionChange and ListBox.OnClick if
selecting a different ListBox item than the currently selected one. Bad.
So the behaviour is inconsistent between platforms, and also
inconsistent within the same control (TListBox) depending on what item
is selected.

Please open an issue about it and I'll take a look on it.

zeljko
--

[kapibara via Lazarus]

Thanks, https://bugs.freepascal.org/view.php?id=31900

Post by zeljko via Lazarus
Please open an issue about it and I'll take a look on it.
zeljko

--

[Graeme Geldenhuys via Lazarus]

Post by kapibara via Lazarus
So the behaviour is inconsistent between platforms, and also
inconsistent within the same control (TListBox) depending on what item
is selected.

I believe I have reported that back in 2006 already. If not the same
component, then one of the list components, but I think it was TListBox
too. I'm afraid LCL is full of inconsistencies like that - between
platforms and between widgetsets. If memory serves me correctly, I was
told it wouldn't be fixed, because such behaviour is dependent on the
underlying GUI toolkit, so developers just have to figure out a
work-around in their applications. Our code became an IFDEF mess, and
shortly afterwards fpGUI was born.

Regards,
Graeme

--