site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com On Nov 16, 2008, at 6:46 PM, David Yamnitsky wrote: On Nov 16, 2008, at 9:32 PM, Steve Christensen wrote: On Nov 16, 2008, at 8:50 AM, David Yamnitsky wrote: Yeah, that's exactly what I did. FxPlug isn't deallocating steve _______________________________________________ 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... 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). If you are releasing the window in your dealloc method then I don't know why it should make any difference when that happens. If the window is still open then perhaps you're plugin's effect class instance hasn't actually been dealloc'd. Did you check for that (either in GDB or by adding some NSLog() calls to your code)? I suppose there could be some differences in the way statically and dynamically created classes are handled that might keep a class instance around in the dynamic case. Perhaps FCP has an optimization for doing so, figuring that it's more expensive (time- wise) to create dynamic class instances. Just a guess. I don't know of anyplace that says it's guaranteed that your class instance will be dealloc'd in a particular fashion so it's probably not wise to make any assumptions on your own. Yeah, I agree. If that is the case, do you know of any workaround that would result in being notified when the effect is deleted? Otherwise the window I create lingers afterwards. Nope, the effect is only called when the host app wants it to do something. To my knowledge there isn't any other notification of when the effect is deleted vs dealloc'd. As for the crash in your window handling code, do you have more details about what's crashing? The crash may not have anything to do with the above issue. The crash isn't really important to this issue. It's caused by an attempt by changes in the window to manipulate FxPlug parameters that don't exist because the effect has been deleted. If the window is released, this won't happen. Well, one of the hazards of having a modeless window associated with a plugin is that the host app creates and deletes instances of your plugin class as they're needed. For example, if you drag your transition class to two points on the timeline, there will be two instances of your class. Otherwise you wouldn't be able to use different parameter settings in each case. This also brings up a usability issue WRT the window: how do you specify which class instance the parameters in the window are referring to? Typically you would use a mix of standard and custom controls as part of the standard plugin UI. If you want to do something more involved, a modal window works better since (a) the parameter changes can only apply to a specific effect instance; and (b) the effect instance can't be dealloc'd before the window is released. This email sent to site_archiver@lists.apple.com