Re: Warnings and tips for using AUGenericView
Re: Warnings and tips for using AUGenericView
- Subject: Re: Warnings and tips for using AUGenericView
- From: Christopher Ashworth <email@hidden>
- Date: Thu, 7 Aug 2008 23:34:44 -0400
Hi Bill,
I agree that for most of the issues I mentioned there appears to be a
reasonable work-around. The one that has me stuck is the final one
described in the post you quoted (i.e. the one below).
I just did some further exploration based on your observation that
AULab has been using the AUGenericView just fine for some time. I
find that if I create a new window and put the AUGenericView inside of
it--no problems. (Modulo the leak described in my previous post.) It
appears that creating a new AUGenericView in its own dedicated window
(which is of course what AULab does) avoids the issue. The AU view
updates itself as the Audio Unit runs, and it is released safely when
the window itself is closed and released.
A (the?) difference in my scenario is that I don't wish to create a
separate dedicated window for the AUGenericView. I have a space in my
existing document window which I want to fill with an AUGenericView
for the currently selected Audio Unit in the workspace. So in my case
the AUGenericView is not released because the owning window is closed,
it's released because it is removed from its superview. And it's this
difference which appears to trigger the bug described below.
Thus, given the way I want to use the AUGenericView, I appear to land
in a catch-22 of the three options described below. Which means I
don't know a way I can make the view fully functional without leading
to a crash or a leak.
Thanks,
Chris
P.S.: And a public "thank you" for all the work the CoreAudio team
does to support us on this list. My own experience has been that I am
much more likely to get help here than other Apple mailing lists. I
guess YMMV, but IMHO ya'll do great work.
On Aug 7, 2008, at 10:25 PM, William Stewart wrote:
Well, I can appreciate your concerns and certainly appreciate your
comments and diagnosis. So, thank you for sharing your hard-won
insights and investigations.
However, I think your conclusion is over-stated. We've been using
this view in AULab now for 2 OS releases and it seems to me to both
usable and stable enough within that context. It could certainly be
the case that we are using it in a very "friendly" manner - like
only creating it when we are going to display it, and not attempting
to manipulate it directly, managing its appearance (and
disappearance carefully, and primarily letting the user control its
sizing (which we do restore when we re-open a document).
From many of the issues that you raised, there does seem to be
workable solutions. I didn't get the impression there was an
absolute deal breaker until I read your conclusion. So, perhaps you
can tell us which particular issue you are most concerned about and
why and we can see if you can sort that out
Thanks
Bill
On Aug 7, 2008, at 2:04 PM, Christopher Ashworth wrote:
On Aug 7, 2008, at 3:38 PM, Christopher Ashworth wrote:
4) The viewWillMoveToWindow bug that leads to a crash, originally
described here:
http://lists.apple.com/archives/coreaudio-api/2007/Nov/msg00019.html
still exists, so be careful how you manipulate your views.
Additionally:
This crash occurs when a call to AUGenericView's
viewWillMoveToWindow: is given nil for the new window. Attempting
to avoid this crash by subclassing AUGenericView does not appear to
be possible, because the retain count of the view is modified by
AUGenericView's implementation of viewWillMoveToWindow. Basically,
the permutations are as follows:
- by default, if you try to remove an AUGenericView from its
superview, viewWillMoveToWindow will be called with a nil newWindow
and you'll crash
- if you subclass AUGenericView and override viewWillMoveToWindow:
to avoid passing it along only when newWindow is nil, the view will
work (including updating controls while the AU runs), but the view
will never be released.
- if you subclass AUGenericView and override viewWillMoveToWindow:
to avoid *ever* passing it along to AUGenericView, the view will
basically work and not get leaked, except that the controls in the
view will not be updated while the AU runs.
If anyone knows some clever way to make AUGenericView usable I'd
love to hear it. Otherwise it appears I'll need to re-implement my
own version of it.
Thanks,
Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden