site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com - Paul On Oct 15, 2007, at 12:59 PM, Benjamin Kent wrote: Thanks Ben Hi, Ben, HTH, - Paul On Oct 15, 2007, at 12:27 PM, Benjamin Kent wrote: Hi Thanks _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... Right. It lets you ask the host, "has the user canceled?" It doesn't let you tell the host, "the user has canceled". And "canceling" in this case means "some activity which has caused a new render", such as moving a slider or stepping to another frame. You should be able to check -userHasCancelled periodically during - renderOutput, and return early if you detect a cancel. That's what it was designed for. It should return YES if the render has been invalidated due to user action since -renderOutput started. I think the behavior during other times (such as an analysis triggered by your custom UI, which FCP doesn't know about) will be less reliable. We probably end up processing the escape key event during our normal event loop, causing -userHasCancelled to forget it happened. I believe FCP's implementation of -userHasCancelled just checks the event queue for an event that means "cancel", so if the keypress has been popped off the queue, we won't see it. In other words, we don't know you have an operation in progress, so we don't know when to reset the cancel flag. I think adding your own cancel button is a good idea. Oh, I see, so it's not really a mechanism to halt processing completely in response to a specific key press (such as the escape key). The reason I need it is to stop an analysis loop in response to a push button which goes through the entire sequence - unfortunately I can only check for userHasCancelled at the end of each frame of processing, and it appears that checking this rarely doesn't seem to catch the interrupt - does this sound believable? In which case I guess I'll just have to add my own cancel button with the push button. Paul Schneider wrote: -userHasCancelled means that you should abort rendering, because some user activity has invalidated your render. In other words, the user is dragging a slider, so the parameters have changed since you started rendering. We will be calling you to render again with the new parameter values, or new time, or whatever else has changed. Each user action triggers a new render; checking for -userHasCancelled lets you abort an invalidated render early so you can move on to the next one. If you want to temporarily disable rendering entirely, so you can adjust a bunch of parameters without any lag, you can hit caps lock in FCP. Motion doesn't have the caps lock mechanism, but they render effects on a secondary thread, so the UI stays responsive. Looking at the Slow_SolidColor example, it would appear that even when you hit escape and the plug-in catches the interrupt with a call to userHasCancelled, the plug-in just gets asked to render again anyway - i.e. the cancelling doesn't really work. Is hitting escape not the correct way to interrupt or is this a bug? Ben _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider% 40apple.com This email sent to pschneider@apple.com This email sent to site_archiver@lists.apple.com