[Lazarus] TCombobox major failure :(
nc-gaertnma at netcologne.de
Tue Jul 15 19:40:59 CEST 2008
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?
More information about the Lazarus