[Lazarus] Article writers wanted.

[Marc Weustink]

Mattias Gaertner wrote:
> 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 necessary at all. See below.
> 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  ;-)