[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    RE: KActions...
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-03-28 11:46:39
[Download RAW message or body]

> On Tue, 28 Mar 2000, Simon Hausmann wrote:
> > On Tue, 28 Mar 2000, Sven Radej wrote:
> > > On Tue, 28 Mar 2000, Simon Hausmann wrote:
> > > >On Tue, 28 Mar 2000, Sven Radej wrote:
> > > >> Hi (Kurt)
> > > >>
> > > >> I have multiple [KToggle | KRadio]actions (setA, setB, setC), and I
> > > >> donīt want to connect each action to its own slot - I want to
connect
> > > >> them all to one common slot which knows which action has been
> > > >> activated, like slotABC(int ID).
> > > >>
> > > >> Question 1: How? I guess KActionCollection should also have signal
> > > >> activated(const char *action_name) or activated (KAction *a).
> > > >
> > > >use sender() :-)
> > >
> > > Ummm...   shouldnīt there be some other way?
> >
> > Hmm, we use sender() quite often in konqueror for this purpose ;-) , and
I
> > admit that I like it (it's sooo handy :-)
> >
> > (or is it really considered to be a bad hack?)
> 
> It's quite dangerous. sender() never gets resetted (can't be 
> done, because at the time where it could be resetted you could have 
> already deleted the object (if you do e.g. a 'delete this' in the slot)). 
> 
> So if you e.g. call directly a slot and before that this slot 
> was called by an object via a signal and this object has been already 
> deleted, sender still points to this already deleted object and
baaaaaaang!

Yes - but this doesn't happen here since actions are not deleted (at least
not
between the activation of an action and the slot being called - actions are
only deleted
when a window (or a part) is deleted). I agree, though, that we should try
to avoid
using it.

Simon, it seems to me that the suggestion above (adding a signal to
KActionCollection)
is matching exactly your idea for the highlighted stuff ? Those two signals
would
make a consistent solution IMHO.

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

[prev in list] [next in list] [prev in thread] [next in thread]