Re: BOOL parameter passed as nil object

On Apr 22, 2016, at 6:19 PM, Quincey Morris wrote: > > On Apr 22, 2016, at 16:12 , Carl Hoefs wrote: >> >> Yes, CFRunLoopPerformBlock: works well! > > But it sounded like you *didn’t* want to prevent the block from running.

Re: BOOL parameter passed as nil object

On Apr 22, 2016, at 16:12 , Carl Hoefs wrote: > > Yes, CFRunLoopPerformBlock: works well! But it sounded like you *didn’t* want to prevent the block from running. In that case, dispatch_async would be all you’d need. (AFAIK, it doesn’t interact with run loops,

Re: BOOL parameter passed as nil object

Yes, CFRunLoopPerformBlock: works well! Thanks, -Carl > On Apr 22, 2016, at 4:09 PM, Clark Cox wrote: > > If you really need the block to run in specific runloop modes, you can use > CFRunLoopPerformBlock: > > > > CFRunLoopPerformBlock(CFRunLoopGetMain(),

Re: BOOL parameter passed as nil object

If you really need the block to run in specific runloop modes, you can use CFRunLoopPerformBlock: CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopCommonModes, ^{ //Code to be performed on main thread }); > On Apr 22, 2016, at 16:00, Carl Hoefs

Re: BOOL parameter passed as nil object

On Apr 22, 2016, at 2:57 PM, Quincey Morris wrote: > > If you must use performSelector, then you can write your own glue method that > takes an object parameter and invokes the API that takes the scalar parameter.

Re: BOOL parameter passed as nil object

> On Apr 22, 2016, at 2:57 PM, Quincey Morris > wrote: > > The recommended way to have them performed on the main thread is to use a > block and GCD dispatch_async (dispatch_get_main_queue (), …). Ahh, that's clean. Implemented and working! That saves me

Re: BOOL parameter passed as nil object

On Apr 22, 2016, at 14:48 , Carl Hoefs wrote: > > does this mean that there is no inherent way to handle the 1000s of > Foundation and AppKit method signatures which don't specify an object but a > value parameter? There is no recommended way to have them

Re: BOOL parameter passed as nil object

> On Apr 19, 2016, at 1:50 PM, John McCall wrote: > > We strongly encourage you not to worry about any of this and just always call > methods using the right method signature. Sorry to beat a dead horse, but does this mean that there is no inherent way to handle the 1000s

Re: BOOL parameter passed as nil object

On Apr 19, 2016, at 1:50 PM, John McCall wrote: > We strongly encourage you not to worry about any of this and just always call > methods using the right method signature. Roger, wilco! (It had a 'smell' to it, but I wasn't quite certain why. Now I know! ;-) -Carl

Re: BOOL parameter passed as nil object

On Apr 19, 2016, at 2:20 PM, Alex Zavatone wrote: > > Considering its use at the language level, would values of nil and 0 result > as NO and every other value of 1 or > == YES? No, when it's a char, there are 254 values which are not == to either NO or YES. This can be a pretty

Re: BOOL parameter passed as nil object

> On Apr 19, 2016, at 1:20 PM, Alex Zavatone wrote: > On Apr 19, 2016, at 3:23 PM, Greg Parker wrote: > >> >>> On Apr 19, 2016, at 12:07 PM, Jens Alfke wrote: >>> On Apr 19, 2016, at 10:22 AM, Alex Zavatone wrote: I believe that

Re: BOOL parameter passed as nil object

> On Apr 19, 2016, at 2:07 PM, Jens Alfke wrote: > > Anyway, I can’t remember if anyone gave a solution to the question. The right > way to do this is to create a new method that takes an NSNumber, and invoke > _that_ method using the delayed-perform, after boxing the BOOL.

Re: BOOL parameter passed as nil object

On Apr 19, 2016, at 3:23 PM, Greg Parker wrote: > >> On Apr 19, 2016, at 12:07 PM, Jens Alfke wrote: >> >>> On Apr 19, 2016, at 10:22 AM, Alex Zavatone wrote: >>> >>> I believe that a BOOL can only be YES or NO. A nil value on a BOOL would >>> be NO if I

Re: BOOL parameter passed as nil object

> On Apr 19, 2016, at 12:07 PM, Jens Alfke wrote: > >> On Apr 19, 2016, at 10:22 AM, Alex Zavatone wrote: >> >> I believe that a BOOL can only be YES or NO. A nil value on a BOOL would be >> NO if I am correct. > > At the language level, yes. Not even

Re: BOOL parameter passed as nil object

> On Apr 19, 2016, at 10:22 AM, Alex Zavatone wrote: > > I believe that a BOOL can only be YES or NO. A nil value on a BOOL would be > NO if I am correct. At the language level, yes. The problem is, this behavior is occurring at runtime, at the machine-code level. The

Re: BOOL parameter passed as nil object

> On Apr 18, 2016, at 6:56 PM, Carl Hoefs > wrote: > > Suppose I have an object with a declared method signature: > -(void)myMethod:(BOOL)a_bool; > > Q1: If I invoke it like this: > [self performSelector:@selector(myMethod:) withObject:nil]; // nil obj >

Re: BOOL parameter passed as nil object

I believe that a BOOL can only be YES or NO. A nil value on a BOOL would be NO if I am correct. Am I correct here? On Apr 18, 2016, at 9:56 PM, Carl Hoefs wrote: > Suppose I have an object with a declared method signature: > -(void)myMethod:(BOOL)a_bool; > > Q1: If I invoke it like this:

Re: BOOL parameter passed as nil object

On Mon, 18 Apr 2016 18:56:43 -0700, Carl Hoefs said: >Suppose I have an object with a declared method signature: > -(void)myMethod:(BOOL)a_bool; > >Q1: If I invoke it like this: > [self performSelector:@selector(myMethod:) withObject:nil]; // nil obj Stop right there, you are violating the

Re: BOOL parameter passed as nil object

What does the compiler say? Not tried this, but as BOOL is neither a pointer nor subclass of NSObject, I would not expect reliable results, but a type mismatch. Of course, I could be wrong, YMMV. Gary On Apr 18, 2016, at 6:56 PM, Carl Hoefs wrote: Suppose I have an object with a

Re: BOOL parameter passed as nil object

On Apr 18, 2016, at 8:56 PM, Carl Hoefs wrote: > > Suppose I have an object with a declared method signature: > -(void)myMethod:(BOOL)a_bool; > > Q1: If I invoke it like this: > [self performSelector:@selector(myMethod:) withObject:nil]; // nil obj > Will

Re: BOOL parameter passed as nil object

To answer your second question consider BOOL b = (BOOL)someObj; if someObj happens to equal something like 0x12345600 the value of b will be NO because casting from a pointer to a char will return the least significant byte. For your first question I don't know exactly but it doesn't look safe;

BOOL parameter passed as nil object

Suppose I have an object with a declared method signature: -(void)myMethod:(BOOL)a_bool; Q1: If I invoke it like this: [self performSelector:@selector(myMethod:) withObject:nil]; // nil obj Will argument a_bool end up with a 0 value assigned to it? Q2: But if I invoke it like this: [self