What could cause a delayed perform (using -[NSObject performSelector:
withObject: afterDelay:]) to never happen? The requested delay is
0.175. I've checked that it's being issued from the main thread, and
I've checked that cancelPreviousPerformRequestsWithTarget: is not being
called. I wonder
On 23 Aug 2018, at 12:06, Alastair Houghton
wrote:
>
> Run loops are based on dispatch queues too, these days.
Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and I
these behave as normal sources without any sign of dispatch queues as far as I
can tell?
I did experim
On 24 Aug 2018, at 20:01, Tor Arne Vestbø wrote:
>
> On 23 Aug 2018, at 12:06, Alastair Houghton
> wrote:
>>
>> Run loops are based on dispatch queues too, these days.
>
> Are they? We use CFRunLoop in the Qt event dispatchers on macOS and iOS, and
> I these behave as normal sources without
On 24 Aug 2018, at 21:16, Alastair Houghton
wrote:
>
> On 24 Aug 2018, at 20:01, Tor Arne Vestbø wrote:
>>
>> On 23 Aug 2018, at 12:06, Alastair Houghton
>> wrote:
>>>
>>> Run loops are based on dispatch queues too, these days.
>>
>> Are they? We use CFRunLoop in the Qt event dispatchers o
On 8/24/18 11:21 AM, James Walker wrote:
What could cause a delayed perform (using -[NSObject performSelector:
withObject: afterDelay:]) to never happen? The requested delay is
0.175. I've checked that it's being issued from the main thread, and
I've checked that cancelPreviousPerformRequestsW
On Aug 24, 2018, at 2:21 PM, James Walker wrote:
> What could cause a delayed perform (using -[NSObject performSelector:
> withObject: afterDelay:]) to never happen?
I'm sure you've checked, but *just in case*, I'll ask: are you sure you're not
sending it to nil?
> I wondered if I needed to do
