Thank you all for the replies! :) Anyway, you've clearly misunderstood. I have clearly not explained properly what I wanted to do, sorry about that. Probably because I'm not quite into the lingo. I've found a great solution, but in case anyone has a technical interest I'll try to explain it better...
Jens Alfke wrote: > On Jan 18, 2010, at 3:38 AM, Per Bull Holmen wrote: > > 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. > > That's not really true. A modal dialog is still running the runloop, > it's just a nested runloop. So at the outer level it looks like the app > has blocked in order to run the modal dialog, what's actually happening > is that the runloop is still in charge and handling events as usual, > it's just ignoring mouse clicks outside that window. When the runloop is > finished with the modal window it returns control back to the original > code. I was not talking about not running the runloop (on the contrary), I was speaking strictly on code level: Write a piece of code that blocks execution and waits for user input, just like I wrote, as opposed to the typical MVC/event driven way, which is marvellous for document based apps and in fact almost all applications, but isn't perfect for every use (even Apple concedes that). Games with intricate branched game logics is one great example. Whether the runtime system runs a runloop, and handles events such as the "quit" command was not part of my question. What I meant was writing code something like this: 1) Do something 2) Block/wait for the user to respond to, say, a question etc... (without having to terminate the function/method and have to store a lot of intermediate variables) 3) Do something with the input. Whether this happens inside a loop was really besides the point. Whether NSRunLoop runs etc... irrelevant. And YES, with a modal dialog you not only CAN do this, it's also often done, and I've done it lots of times. NSRunAlertPanel and NSOpenPanel are two, very simple examples. (that is, when you call it, the calling code is blocked untill the modal session is over). The only problem with the modal way, in this case, is that it only accepts input from one single window. > What you're talking about is an inverted flow of control where your code > is in charge and periodically calls the runloop to handle an event. It's > possible to write code that way, but it gets really messy in the real > world because you're privileging one possible flow of control while > ignoring the others. So you may be waiting for the user to press button > A or button B, but what happens if the user decides to choose the Quit > command? Now your loop has to handle that too. What you'll end up with > is an explosion of different cases in your event-handling code, which > gets just as messy as the normal flow of control would have been, only > worse because all the complexity is in one big switch statement. Again, I have clearly not explained what I wanted to do properly. No, I did not want what you describe. I have done it now, I chose to use threads, and it got far cleaner than the "standard Cocoa way". No, I don't have to handle any other input than what's relevant for the game, Cocoa handles the rest, thank you... :) The thing is that the way Cocoa usually handles things is really great for the vast majority of apps, but in an interactive game with an intricate, branched flow of game logic, you'll sometimes want to write the game logic in more coherent pieces of code that focus on logic/control flow, rather than updating a lot of intermediate state variables. It just gets cleaner, more maintainable, and more extensible this way. I was able to do this great within the Cocoa system, I just had to write a simple, sort of a mediating layer between the game controller (which runs in a separate thread) and the main UI thread. I really appreciate your replies! I must have explained it poorly... anyway if someone still want to convince me I'm doing things the wrong way, then I'm guessing either they are so in love with MVC they have lost their sense of reality, or they still haven't understood what I'm trying to explain... :) Per _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
