[Lazarus] TCombobox major failure :(

[Mattias Gaertner]

On Sat, 12 Jul 2008 15:28:10 -0300
Luiz Americo Pereira Camara <luizmed at oi.com.br> wrote:

> Luiz Americo Pereira Camara wrote:
> > Mattias Gaertner wrote:
> >   
> >> My question is:
> >> What about the other widgetsets?
> >>     
> 
> Qt also sends LM_CHANGED + LM_SELCHANGE
> 
> >> 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 the most doable solution . See below.
> 
> > 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.
> >   
> 
> Gtk2 is handled in an different callback function. Unlike gtk1 the 
> LM_SELCHANGE message is sent inside the 'changed' event. At first
> look is not possible to determine if the changed event came from the 
> selection list or not.
> 
> One issue is that in gtk2 and Qt the LM_CHANGED message is sent
> before LM_SELCHANGE unlike gtk1, but gtk1 could be reimplemented like
> gtk2. Under Win32 is easy to sent an extra LM_CHANGED message in
> response to selection change

It seems, there are no objections. Will you do it?

Mattias