RE: Blocking Method Return
RE: Blocking Method Return
- Subject: RE: Blocking Method Return
- From: "Josh Ferguson" <email@hidden>
- Date: Fri, 2 Dec 2005 09:19:24 -0600
- Thread-topic: Blocking Method Return
Simply put, I don't have that design flexibility. Regardless, it's
certainly not an argument against windows apps. Classic Mac apps and
most unix libraries employ the same tactic - you call into a function,
wait for it to return, and grab the return value. It's not like it's a
terrible paradigm. It's just not very cocoa-friendly.
Regardless, I've gotten it working for the most part. I employ a loop
like this:
While(!done && (event = [NSApp nextEventMatchingMask:NSAnyEventMask
untilDate:[NSDate distantFuture] inMode:NSDefaultRunLoopMode
dequeue:YES]))
{
If([event window] == _window)
[NSApp sendEvent:event];
}
This also seems to solve my problem with the keyboard focus not
returning to the window. There must be an event that is sent to NSApp
that never gets sent explicitly to NSWindow to retrieve the focus when
the window is brought back to the front.
-----Original Message-----
From: I. Savant [
mailto:email@hidden]
Sent: Friday, December 02, 2005 8:35 AM
To: Josh Ferguson
Cc: j o a r; email@hidden
Subject: Re: Blocking Method Return
... one argument against Windows apps. :-) I agree with Joar - why
not change the design a bit? Use a spinner and keep the "go on to the
next step" button(s) disabled until the operation is complete. That
strikes me as far more Mac-like.
--
I.S.
On Dec 2, 2005, at 9:19 AM, Josh Ferguson wrote:
>
I'm actually writing a cross-platform library. On the windows side,
>
when
>
a user calls into a function, that function does not return until all
>
operations are complete.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden