Re: [Lazarus] TListView OnSelectItem event: Bug or feature?
Il 22/08/2014 16:44, Michael Thompson ha scritto: The implementation of the OnSelectItem event of TListView doesn't appear to me to be correct. With MultiSelect false, selecting a new Item on the list generates, as expected, two events: the unselect of the previous Item, and the select of the new one. But they're generated in the reverse order. i.e. first the selection of the new one, then the unselect of the old one. Out of curiosity, which widgetset are you using? My memory (haven't checked this for at least 3 years) says the events were fired in different sequences between different widgetsets. Mind you, I can't think of how a change in event order will affect any of the examples you've given. This behavior is common at least to GTK2 and Qt. That's why I think it originates in LCL. I consider it a bug, because the last event generated doesn't represent the actual final status of TListView (i.e. an Item selected or no Item selected), but may represent a previous intermediate condition. Extra code in application is required to sort out things. There are many differences between different widgetset TListview implementation, and a lot of care must be exercised if you want your application behave the same way in all condition. e.g.: under Qt a programmatical select of an Item doesn't unselect the previous one, even if MultiSelect is not active, and a programmatical unselect of an Item doesn't trigger the OnSelectItem event if ViewStyle is vsList, but does trigger it if the ViewStyle is vsReport! Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] TListView OnSelectItem event: Bug or feature?
The implementation of the OnSelectItem event of TListView doesn't appear to me to be correct. With MultiSelect false, selecting a new Item on the list generates, as expected, two events: the unselect of the previous Item, and the select of the new one. But they're generated in the reverse order. i.e. first the selection of the new one, then the unselect of the old one. Out of curiosity, which widgetset are you using? My memory (haven't checked this for at least 3 years) says the events were fired in different sequences between different widgetsets. Mind you, I can't think of how a change in event order will affect any of the examples you've given. Mike -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] TListView OnSelectItem event: Bug or feature?
Hi Lazarus team, The implementation of the OnSelectItem event of TListView doesn't appear to me to be correct. With MultiSelect false, selecting a new Item on the list generates, as expected, two events: the unselect of the previous Item, and the select of the new one. But they're generated in the reverse order. i.e. first the selection of the new one, then the unselect of the old one. This requires extra code in the application to verify if there's still an item selected or not: just handling the events one by one doesn't let you tell apart an unselect caused by other reasons (such as the selected item being deleted, or a programmatical unselection), from an unselect generated by a new select. Is this a feature required to be bug-compatible with Delphi, or a bug of LCL of its own? Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
