[Interest] Handling signal-slot connections on demand (sanity check request)

[André Somers]

Hi,


Op 28/01/2017 om 01:33 schreef Forrest Leeson:
> Assume an application that creates a focusable dialog with 9 buttons.
> Clicking buttons 1-8 causes the creation of new windows — type 1
> through type 8, each type supporting a slot, S, that can be connected
> to the signal of button 9.
>
> Clicking button 9 should trigger slot S only of the window that was
> most recently active. Which is to say the connection can't usefully be
> set up when the window is created.
>
> A solution would seem to be to add a look-at-me signal to all the
> window types, which they would emit to the dialog upon receiving
> focus; the receiver would then [ disconnect(Button9,0,0,0) ] and then
> connect Button 9 to the signalling window's slot S by way of
> QObject::sender() with a side order of qobject_cast...at which point I
> am realize I am stupid and ignorant and have misplaced all my B
> vitamins and choline supplements and my coffee is cold and foul.
> The documentation warns against using Sender this way, but chides
> rather than forbids. Look-at-me signals not arriving in order would be
> a dealbreaker, but unless I'm misreading, establishing the connection
> with Qt::DirectConnection will fix that. And I guess checking for 0
> against the result of the cast will avoid crashing.
>
> So: is this approach even minimally sane, and even if so is there a
> (better) way to do it?
Why do you maintain a connection to each of the windows at all? It seem 
to me that it would be much easier keeping track of which of your 
windows 1..8 is active (monitor for the occurance of 
QEvent::WindowActivate in your application via an event filter), and 
then on triggering button 9 simply call the indicated method S on that 
window.

André