site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Thanks for all the help! David On Nov 17, 2008, at 11:31 AM, Paul Schneider wrote: Hi David, I'll assume that you see this problem in FCP and not Motion? - Paul On Nov 16, 2008, at 10:50 AM, David Yamnitsky wrote: Thanks in advance, David _______________________________________________ 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 _______________________________________________ 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... It seems that the most stable option is to go modal... I tested the example code, and the same thing occurred as in my code. When the effect was deleted, the window wasn't released and clicking the "Re-render" button caused a crash. I believe that when an effect is "deleted" in FCP, it is actually transferred to the undo stack, where it hangs out until either a) the user hits undo to bring it back, or b) the "delete effect" action falls off the stack. The second one can happen if the stack gets full (I think by default, we cap it at 20 actions, but you can adjust this in the preferences), or if the user does something to take undo down a different branch (like adding a different effect). This would explain why you don't get a -dealloc message when you delete the effect, and why you receive -dealloc at a seemingly random time later. I don't know why your plugin behaves differently from the example in this respect; I'd actually expect the example to have the same problem. I can investigate that. Without a crash report, I can't speculate on why you are crashing, but it sounds like you're manipulating the parameters of an effect which only lives on the undo stack (isn't applied to any clip or sequence), and I wouldn't be surprised if that confused Final Cut. We won't send you a separate "the effect has been deleted, as far as the user's concerned" message, so there's not much you can do to trap this case. We should probably dealloc FxPlugs when they're removed from the clip, and re-alloc them if that removal is undone. Please file an enhancement request at bugreport.apple.com if you'd like that behavior. In the meantime, I think you will have some problems trying to manage a floating window from an FxPlug in Final Cut. I know that there's a problem where FCP won't refresh the canvas if you change a parameter which isn't loaded in the viewer's control tab, and it sounds like you've found a second issue. I'd recommend sticking to a modal UI for now. Hi everyone, I'm building a plugin which opens a separate window. It all works fine, except I'm having the problem that when the effect is deleted, the window remains open. Any attempt to manipulate something in the window which makes an FxPlug API call crashes the app. I consulted the FloatingWindow example code, which just releases the window when -dealloc is sent to the plugin object, which is the same thing I'm doing. I did some digging, and found that the FloatingWindow example receives the -dealloc call right when the effect is deleted, but my plugin receives that call rather spontaneously, either when the app is quit or when another effect is applied. Why is this? Could it be because my plugin is dynamically registered? (that seems to be the only obvious difference between the FloatingWindow example and my code). This email sent to pschneider@apple.com This email sent to site_archiver@lists.apple.com