Qt-interest Archive, December 2007
Child widget focus
Message 1 in thread
Is there any way to determine when a child widget looses focus?
I'm working on a control right now where I need to know when one of my
child widgets has lost focus so that I can destroy that widget as it's
no longer needed then. But looking at QWidget I see absolutely no
signals that I could use for this purpose.
Since my child widget can be any kind of widget, I can't subclass
focusOutEvent in the child widget.
Thanks,
Stephan
--
[ signature omitted ]
Message 2 in thread
> Since my child widget can be any kind of widget, I can't subclass
> focusOutEvent in the child widget.
install an eventfilter for that event instead:
http://doc.trolltech.com/4.3/eventsandfilters.html#event-filters
http://doc.trolltech.com/4.3/qobject.html#installEventFilter
Cheers,
Peter
--
[ signature omitted ]
Message 3 in thread
On Thu, 2007-12-27 at 14:31 +0100, Peter Prade wrote:
> > Since my child widget can be any kind of widget, I can't subclass
> > focusOutEvent in the child widget.
>
> install an eventfilter for that event instead:
> http://doc.trolltech.com/4.3/eventsandfilters.html#event-filters
> http://doc.trolltech.com/4.3/qobject.html#installEventFilter
Thanks, that does the trick.
However, doesn't this completely defeat the purpose of having signals
and slots?
Stephan
--
[ signature omitted ]
Message 4 in thread
On Dec 27, 2007, at 8:43 AM, Stephan Rose wrote:
> On Thu, 2007-12-27 at 14:31 +0100, Peter Prade wrote:
>>> Since my child widget can be any kind of widget, I can't subclass
>>> focusOutEvent in the child widget.
>>
>> install an eventfilter for that event instead:
>> http://doc.trolltech.com/4.3/eventsandfilters.html#event-filters
>> http://doc.trolltech.com/4.3/qobject.html#installEventFilter
>
> Thanks, that does the trick.
>
> However, doesn't this completely defeat the purpose of having signals
> and slots?
Then use the QApplication::focusChanged() signal, and check the old
and now widgets to see if they are your children.
--
[ signature omitted ]
Message 5 in thread
On 27.12.07 14:43:50, Stephan Rose wrote:
>
> On Thu, 2007-12-27 at 14:31 +0100, Peter Prade wrote:
> > > Since my child widget can be any kind of widget, I can't subclass
> > > focusOutEvent in the child widget.
> >
> > install an eventfilter for that event instead:
> > http://doc.trolltech.com/4.3/eventsandfilters.html#event-filters
> > http://doc.trolltech.com/4.3/qobject.html#installEventFilter
>
> Thanks, that does the trick.
>
> However, doesn't this completely defeat the purpose of having signals
> and slots?
No, there are things that are better done with Events than signals and
slots. In particular Events can be combined into one, like paint events,
whereas a slot connected to a signal is always executed as many times as
the signal is emitted.
Last but not least: I trust that there's a reason events exist in Qt, so
there probably are more reasons to have no signals for some things that
are currently done by events.
Andreas
--
[ signature omitted ]
Message 6 in thread
On Thu, 2007-12-27 at 21:24 +0100, Andreas Pakulat wrote:
> On 27.12.07 14:43:50, Stephan Rose wrote:
> >
> > On Thu, 2007-12-27 at 14:31 +0100, Peter Prade wrote:
> > > > Since my child widget can be any kind of widget, I can't subclass
> > > > focusOutEvent in the child widget.
> > >
> > > install an eventfilter for that event instead:
> > > http://doc.trolltech.com/4.3/eventsandfilters.html#event-filters
> > > http://doc.trolltech.com/4.3/qobject.html#installEventFilter
> >
> > Thanks, that does the trick.
> >
> > However, doesn't this completely defeat the purpose of having signals
> > and slots?
>
> No, there are things that are better done with Events than signals and
> slots. In particular Events can be combined into one, like paint events,
> whereas a slot connected to a signal is always executed as many times as
> the signal is emitted.
>
> Last but not least: I trust that there's a reason events exist in Qt, so
> there probably are more reasons to have no signals for some things that
> are currently done by events.
>
True, I'm definitely not saying eliminate events. They definitely have
their place and are needed. But still, I think having some signals
available for the standard typical events that are going to occur in a
widget might not be that terribly bad an idea.
--
[ signature omitted ]
