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, 4 Sep 2008 12:28:58 -0400
For the benefit of the list, the CoreAudio guys guided me to a
workaround that I wanted to share: add a borderless child window to
the place in my document where I want to display an AUGenericView.
Receive frame changed notifications for anything that might affect the
frame of the AU view and update the child window as necessary. In
effect, make it look like it's in a subview of the document even
though it gets its own window to live in.
A little extra work, but it allows everything to work as advertised;
no leaks, no crashes, and no misbehaving views.
Best,
Chris
On Aug 7, 2008, at 11:34 PM, Christopher Ashworth wrote:
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