> Wow! Although you and the other list members have my profuse apologies for > missing that, I thought that my case was so unique that I didn't actually > think to look for that particular aspect of NSOperation -- > right-under-the-nose, eh? -- and instead just came up with the term on my > own. I really appreciate your pointing that out, I.S.
Meh ... we all miss stuff, especially if we work with multiple environments / APIs, etc. >> ... what happens if a logging operation is still in progress when the main >> algorithm is stopped? Ideally, would one simply stop the most recent >> logging operation? Stop all of them? Stop none of them, and simply let >> them run their course? I can see cons to all of these, and can't quite >> figure out what's best (e.g., for the first, what if the most recent logging >> operation belongs to a *previous* incarnation of the main algorithm, and not >> the one that's presently running? For the second, what if the user doesn't >> want to interrupt his or her logging, again for previous rolls, with the >> cancellation of the main algorithm? and, for the third, what if the user >> *wants* to interrupt one or all of the logging operations??). > > While dependent operations may produce a particular behavior, or be > configurable to produce certain behaviors, what behavior would be a best > practice from a UI and user-experience perspective? It really, truly depends on your application requirements. If the logging for "roll 1" is dependent on that roll, you'll be adding the "roll" and "log" operations in tandem (with appropriate dependancies) to your queue, right? So if the roll is canceled, so would be its associated log operation, correct? With this behavior, if a roll is cancelled, it won't be logged. I presume that if the roll occurred uninterrupted, you'd want it logged, so the user shouldn't be able to cancel a log event for a completed roll. Again, this depends on your requirements. Maybe a bit more in-depth explanation is required. -- I.S. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
