Re: Plugin not receiving -dealloc call at the expected time
Re: Plugin not receiving -dealloc call at the expected time
- Subject: Re: Plugin not receiving -dealloc call at the expected time
- From: Steve Christensen <email@hidden>
- Date: Sun, 16 Nov 2008 22:09:02 -0800
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:
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)?
Yeah, that's exactly what I did. FxPlug isn't deallocating
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.
steve
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden