GUICtrlSetOnEvent registeres also on Listviewitems created with _GUICtrlListView_AddItem and lparam

[Qsek]

When using OnEventMode, GUICtrlSetOnEvent seems to also fire when you click on Listviewitems created with _GUICtrlListView_AddItem
If the $iParam is the same as a controlID of an control on which GUICtrlSetOnEvent is bounded, a click on this Listviewitem will run the associated OnEvent function, as if you would have clicked the control.
See attached example 2.au3
click on item 4 and 5
Qsek

[Qsek]

Attachment to Ticket #1011

[Gary]

Not a bug, Application defined data is just that, you need to make sure that if you use lparam to start at a number higher than any control already created to not have the same application defined data value.

[Gary]

see the example2 for _GUICtrlListView_RegisterSortCallBack in the help file

[anonymous]

hmm ok so as i understand lparam sets the controlID of the LVitem?
This should be mentioned somewhere in the help.
I can be a really annoying bug if you work with LV's and lparam.
But do you think it is good that it is possible to create a control(LVitem) that has the same ControlID as another control?
and why is it only affecting GUISetOnEvent? Normally you should be able to use GUICtrlSetData and the other control functions if you set the lparam.

[Valik]

Replying to anonymous:

hmm ok so as i understand lparam sets the controlID of the LVitem?

Not quite. Due to poor design in AutoIt, the LPARAM is internally used to store the control ID that AutoIt returns. That means it's not possible to use the LPARAM of built-in ListViewItems without breaking AutoIt's handling. Likewise it makes it so that even users who are not using the built-in control and are instead using the Windows API directly can't effectively use the LPARAM without clashing.

You should never mix built-in and UDF controls. Use one or the other, not both.