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 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OrderOfEvents.zip
Type: application/zip
Size: 2458 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170522/b99f9f96/attachment.zip>

Showing events.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EventOrder.png
Type: image/png
Size: 18252 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170522/91a37c65/attachment-0001.png>

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.. -------------- next part --------------
A non-text attachment was scrubbed...
Name: event_orders_win.png
Type: image/png
Size: 10967 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170523/a21bc65c/attachment.png>

kapibara wrote

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()

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

zeljko wrote

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 Delphi 7 doesn't have the ListBox.SelectionChange event:

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 Windows Lazarus and Delphi 7:

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 wrote

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

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

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