<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Delayed Signals</title>
	<link>http://delta.affinix.com/2006/04/14/delayed-signals/</link>
	<description>Building an XMPP/Jabber Platform</description>
	<pubDate>Fri, 25 Jul 2008 17:18:37 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.2</generator>
		<item>
		<title>By: justin</title>
		<link>http://delta.affinix.com/2006/04/14/delayed-signals/#comment-26</link>
		<dc:creator>justin</dc:creator>
		<pubDate>Sat, 15 Apr 2006 01:02:00 +0000</pubDate>
		<guid>http://delta.affinix.com/2006/04/14/delayed-signals/#comment-26</guid>
		<description>Hi Camel,

Normally when I want to explicitly delay a signal, I use QMetaObject::invokeMethod(), which at least allows for argument handling.  I used QTimer::singleShot() in the code above because I thought it would be more familiar to readers and I could get away with it (since quit() has no args).

Good tip about the loopback connection, though.  I'd forgotten about that one.  It allows for safer argument handling than invokeMethod.</description>
		<content:encoded><![CDATA[<p>Hi Camel,</p>
<p>Normally when I want to explicitly delay a signal, I use QMetaObject::invokeMethod(), which at least allows for argument handling.  I used QTimer::singleShot() in the code above because I thought it would be more familiar to readers and I could get away with it (since quit() has no args).</p>
<p>Good tip about the loopback connection, though.  I&#8217;d forgotten about that one.  It allows for safer argument handling than invokeMethod.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Camel</title>
		<link>http://delta.affinix.com/2006/04/14/delayed-signals/#comment-25</link>
		<dc:creator>Camel</dc:creator>
		<pubDate>Fri, 14 Apr 2006 15:59:32 +0000</pubDate>
		<guid>http://delta.affinix.com/2006/04/14/delayed-signals/#comment-25</guid>
		<description>of course that should read:
connect(this, SIGNAL(quit_p()), this, SIGNAL(quit()), Qt::QueuedConnection);</description>
		<content:encoded><![CDATA[<p>of course that should read:<br />
connect(this, SIGNAL(quit_p()), this, SIGNAL(quit()), Qt::QueuedConnection);</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Camel</title>
		<link>http://delta.affinix.com/2006/04/14/delayed-signals/#comment-24</link>
		<dc:creator>Camel</dc:creator>
		<pubDate>Fri, 14 Apr 2006 15:58:46 +0000</pubDate>
		<guid>http://delta.affinix.com/2006/04/14/delayed-signals/#comment-24</guid>
		<description>Couldn't you create signals:
signals:
        void quit();
        void quit_p();

and then in the constructor do a:
connect(this, SIGNAL(quit()), this, SIGNAL(quit()), Qt::QueuedConnection);

which should emit the signal quit()  as soon as control reaches the event loop after an emit quit_p(). nice thing is you can still use the normal emit syntax which helps with parameters.</description>
		<content:encoded><![CDATA[<p>Couldn&#8217;t you create signals:<br />
signals:<br />
        void quit();<br />
        void quit_p();</p>
<p>and then in the constructor do a:<br />
connect(this, SIGNAL(quit()), this, SIGNAL(quit()), Qt::QueuedConnection);</p>
<p>which should emit the signal quit()  as soon as control reaches the event loop after an emit quit_p(). nice thing is you can still use the normal emit syntax which helps with parameters.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
