Re: Blocking for input during a loop?
Re: Blocking for input during a loop?
- Subject: Re: Blocking for input during a loop?
- From: Per Bull Holmen <email@hidden>
- Date: Mon, 18 Jan 2010 03:38:36 -0800 (PST)
> ----- Original Message ----
> From: Kyle Sluder <email@hidden>
> To: Per Bull Holmen <email@hidden>
> Cc: email@hidden
> Sent: Mon, January 18, 2010 6:29:32 AM
> Subject: Re: Blocking for input during a loop?
>
> > On Sun, Jan 17, 2010 at 1:59 PM, Per Bull Holmen <email@hidden> wrote:
> > Is it possible, in Cocoa, do program a loop which goes something like this:
> >
> > for i=1 to 20
> > do something
> > block for GUI user input
> > do something with the input
> > repeat
>
> This is a bad idea. Don't block the UI thread, because then the user
> will see a beachball.
>
> Sounds like you need to reread the Cocoa Event Handling Guide:
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/EventOverview/Introduction/Introduction.html
>
> Your architectural difficulties also betray an unfamiliarity with MVC
> design. I suggest you read the Cocoa Design Patterns section of the
> Cocoa Fundamentals Guide, delve into the AppKit classes to see how
> that document relates to the actual framework, and then iterate your
> own design over and over (perhaps with pencil and paper for a while),
> keeping in mind the things you've learned from the documentation and
> from using the classes in AppKit. AppKit classes need to maintain a
> lot of state information, particularly when doing things like dragging
> or other input-driven processes. Here is the relevant document:
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW6
>
> --Kyle Sluder
Thanks for the response.
I have created several applications the "standard Cocoa way" so to speak, since 10.2, using the target/action mechanisms, responder chain, bindings, and MVC-paradigm. It's great! This time, I firstly also did it the way I'm used to doing it, but as I thought I had explained to you, it got very cumbersome for me to use for the task at hand. The controller classes got very complex, with too many state variables - too many potential bugs, it got very difficult to extend, so I thought I'd find another way of doing it. I am absolutely convinced that I should learn a lot more about the stuff you want me to read, and it's quite possible I could have done it better, but I do have a problem with you asking me to read about 500 pages of documentation, without first giving me a reason to believe it would solve my problem.
You say my initially proposed loop is a bad idea - but lots of applications use this type of loop. The difference is that they do it only inside one window, and block user access to all other parts of the application (modal windows). They do this for wizards and the like, which are far closer to how the game will eventually be than a "regular" application. So, maybe that's the way to go? As I thought I had made clear, the loop doesn't have to happen in the UI (main) thread. It's just that if the loop wants to interact with views, controls etc., I'd have to arrange for messaging to the main thread, which could also get awkward.
Per
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden