Mattias Gaertner wrote 5 lines
I read the thread again and will try to summarize it. Please confirm or
correct me:
When the user selects an item via the popup list, then an LM_SELCHANGE
event should be fired.
Correct. Win32, Gtk1 and Gtk2 does this currently.
OTOH the text changes too, so the LM_CHANGE
event makes sense too.
Yes. Works fine in Win32, Gtk1 and Gtk2 (as far as i remenber)
But according to Luis the winapi does not send
the LM_CHANGE.
Ok
The VCL follows the winapi and triggers only an OnSelect,
but not an OnChange.
Ok. It will map the WM_SELCHANGE to an OnChange event if OnSelect is not is set
I agree with Luis the winapi (and VCL) is somewhat inconsistent here,
because you can not use OnChange to follow every change.
Luis was fearless enough to write some gtk signal stops to mimic the
winapi behavior.
It's my hacker vein in action ;-)
I think this sounds too much like emulating the
winapi, which is not the goal of the LCL.
Ok. It's not below.
Show quoted text 8 lines
My question is:
What about the other widgetsets?
Can they easily distinguish between a popup selection change and
other changes?
If not, then we should redefine the LM_CHANGE, LM_SELCHANGE events for
the combobox. The TComboBox should be Delphi compatible, the
messages don't need to be.
One drawback, although unlikely, is if an descendant intercept LM_* messages.
For example: It is quite simple to add a LM_CHANGE in the win32 intf.
TComboBox could check before triggering an OnChange if something has
changed, which should be quite Delphi compatible.
It's an option. Another option (simpler) is see why the current code to avoid the LM_CHANGED message works for Gtk1 and not for gtk2. See if is possible under detect under gtk2. I'll see.
Luizzzzzzzzzzzzzzz ;-)
