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

Forrest Leeson forrestuuid at gmail.com
Tue Jan 31 07:39:51 CET 2017

As to obviating the need for emitting a signal by installing an event
filter — well, that's one of those better ideas I was hoping for,
along with the C++11 ampersand method mentioned by the other André
(thanks to both of you).

Maintaining a connection — I didn't want to, hence the
disconnect(Button9,0,0,0) — I wanted to establish a temporary one at
the activated window's discretion.

On Mon, Jan 30, 2017 at 10:41 AM, André Somers <andre at familiesomers.nl> wrote:
> 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é
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

More information about the Interest mailing list