Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Abdelrazak> But setFocus has to be called... either explicitly or via
Abdelrazak> a signal/slot connection. I don't see that any call to it
Abdelrazak> in your patch and I didn't find a call to
Abdelrazak> QtView::setFocus() elswhere.

But QMainWindows::setFocus (or QWidget::setFocus) gets called,
according to Qt docs.

Maybe that a Qt3 thing then. Called by which class at which moment?

At least this is not automatic call is I read correctly Qt3.3 doc:

void QWidget::setFocus () [virtual slot]
Gives the keyboard input focus to this widget (or its focus proxy) if this widget or one of its parents is the active window.

First, a focus out event is sent to the focus widget (if any) to tell it that it is about to lose the focus. Then a focus in event is sent to this widget to tell it that it just received the focus. (Nothing happens if the focus in and focus out widgets are the same.)

setFocus() gives focus to a widget regardless of its focus policy, but does not clear any keyboard grab (see grabKeyboard()).

Be aware that if the widget is hidden, it will not accept focus.

Warning: If you call setFocus() in a function which may itself be called from focusOutEvent() or focusInEvent(), you may get an infinite recursion.

I am overriding a virtual function, or at least
I try to.

It is not a pure virtual function. Calling QMainWindows::setFocus() will effectively call QWidget::setFocus() not QtView::setFocus().

The fact that I do not really understand qt signal/slots does not
help.

Maybe you are mixing slots with events which are there to be overloaded. A slot needs to be manually connected to a signal or manually called. Only Qt4 has the concept of automatic slots.

Hope this helps,
Abdel.


Reply via email to