[Qt] QT binding anomalies

[zeljko]

On Friday 05 March 2010 15:49, Juha Manninen wrote:
> > I told you that it's my test case for something (don't know what
> > purpose), so change code according your needs. No, you don't need
> > separate FDropList. You can reach items from QComboBox_view() abstract
> > item view (which is QListWidget afaik).
>
> Right, but your LCL binding code also has a separate FDropList. Actually I
> was thinking of that when I asked my question.
>
> function TQtComboBox.GetDropList: TQtListWidget;
> begin
>   if FDropList = nil then
>   begin
>     FDropList := TQtListWidget.CreateFrom(LCLObject, QListWidget_create());
>     FDropList.setAttribute(QtWA_NoMousePropagation, False);
>     FDropList.OwnerDrawn := OwnerDrawn;
>     QComboBox_setModel(QComboBoxH(Widget), FDropList.getModel);
>     QComboBox_setView(QComboBoxH(Widget), QListWidgetH(FDropList.Widget));
>   end;
>   Result := FDropList;
> end;
>
> However, it seems to work in the qt only pascal app without blinking so is
> was not the problem.
> But, now I found a big (?) difference:
>
>     FLineEdit: TQtLineEdit;
>     FDropList: TQtListWidget;
>
> So, there is not only a separate DropList but also a separate LineEdit !
> Your qt only pascal app doesn't have it.
> I feel we are nearing the essence of the problem... :-)

FLineEdit & FDropList are implemented because of:
1.Controlling autocompletion by LCL
2.Controlling selection length (selstart,selstop) by LCL
3.Allow owner draw for combo box (without FDropList it's impossible).
etc etc
So, it must be like that and it won't be changed, since qtlcl combobox will be 
almost unuseable with lcl (many properties will not work).

> Why are those sub-controls separated if the QT control already provides
> them built-in? I ask it because I don't know the code well. I am ready to
> experiment with the LCL bindings code but I guess you have already tried
> the obvious solutions and there was a problem and then you ended up with
> the current solution.
>
> There is also a variable:
>     FDropListVisibleInternal: Boolean;
> which (I guess) means you were testing with both built-in and internal
> DropLists.

No, it's there to avoid IntfGetItems() call if list is visible.



zeljko