How do I prevent an NSButton from registering presses while disabled? - cocoa

Question

Newbie Warning
I have a simple but vexing problem trying to disable an NSButton. Here is sample code to illustrate the problem:
- (IBAction)taskTriggeredByNSButtonPress:(id)sender {
[ibOutletToNSButton setEnabled:NO];
//A task is performed here that takes some time, during which time
//the button should not respond to presses.
//Once the task is completed, the button should become responsive again.
[ibOutletToNSButton setEnabled:YES];
}
This is what I observe. I press the button. The button becomes disabled (judging by its faded appearance), and the task begins executing. While the button is disabled and the task is executing, I press the button a second time. Nothing happens immediately, but once the task is completed, the taskTriggeredByNSButtonPress: method is called a second time, suggesting that the second button press was placed on hold and then activated once the button became re-enabled.
I've tried all kinds of hacks to prevent the second button press from being recognized, including introducing a time delay after the [ibOutletToNSButton setEnabled:NO]; statement, making the button hidden rather than disabled, covering the button with a custom view during the time it should be disabled, binding the button's enabled status to a property, and other things I'm too embarrassed to mention.
Please help me understand why I can't get this simple task of disabling the button to work.

Answer 1

This method seems to be directly linked to the button. You should perform the long action on another thread, or the main runloop won't be available until the method returns. The main runloop doesn't respond to events while it's not available.
First, create a method:
- (void)someLongTask: (id)sender {
// Do some long tasks…
// Now re-enable the button on the main thread (as required by Cocoa)
[sender performSelectorOnMainThread: #selector(setEnabled:) withObject: YES waitUntilDone: NO];
}
Then, perform that method in a separate thread when the button's clicked:
- (IBAction)buttonPushed: (id)sender {
[sender setEnabled: NO];
[self performSelectorInBackground: #selector(someLongTask) withObject: nil];
}
You may replace self in the example above with the object where -someLongTask resides.
By multi-threading, you leave the main runloop alone and stable. Maybe, your problem will be solved. Otherwise, you solved a problem with responsiveness.
(By the way, if the method is only called by the button, the sender argument is set to the button. That way, you don't need to use an outlet in the method. But that's just a hint.)

Answer 2

You should not perform tasks that require a lot of processing time on the main event loop. This is what you are doing, and the app's entire UI will block while your code executes. Blocking the main thread is the cause of the Spinning Pizza of Death™. In other words, don't do it.
What you need to do instead is break out your time-consuming code so that it runs in another thread, that is, concurrently in the background. When the background task completes, it should somehow notify the code running in the main thread that it has finished. Your code in the main thread can then update the UI appropriately.
There are many ways to do this.
You can use the NSThread methods as suggested by Randy Marsh. However, you must be very careful to read the documentation, as you can't just call any old method on a background thread and expect it to work. You must create your own autorelease pool in the thread and dispose of it correctly. You must NOT call any methods that update the UI from a secondary thread. You must be extremely careful that no variables will be accessed or modified by more than one thread at a time. Threading is a complex business.
The -performSelectorInBackground:withObject: method of NSObject is essentially a simple way of using NSThread and has the same provisos.
You can use the NSOperation and NSOperationQueue methods, which are especially good if you can break down your task's work into small chunks that can be executed simultaneously.
The simplest way of handling this is GCD (Grand Central Dispatch), which allows you to use inline blocks to write background processes:
- (IBAction)taskTriggeredByNSButtonPress:(id)sender
{
[ibOutletToNSButton setEnabled:NO];
//get a reference to the global GCD thread queue
dispatch_queue_t queue = dispatch_get_global_queue(0,0);
//get a reference to the main thread queue
dispatch_queue_t main = dispatch_get_main_queue();
//perform long-running operation
dispatch_async(queue,^{
NSLog(#"Doing something");
sleep(15);
//update the UI on the main thread
dispatch_async(main,^{
[ibOutletToNSButton setEnabled:YES];
});
});
}
GCD is very lightweight and efficient and I highly recommend you use it if possible.
There is a lot more information and detail in Apple's Concurrency Programming Guide, which I recommend you read, even though some of the detail may be beyond you at this stage.