Re: Resizing AU Views (Carbon)
Re: Resizing AU Views (Carbon)
- Subject: Re: Resizing AU Views (Carbon)
- From: William Stewart <email@hidden>
- Date: Fri, 5 Dec 2003 15:37:53 -0800
Correction! As Marc pointed out to me, this *isn't* in the current
SDK...
We're cleaning up some pieces now, and hope to have a revised SDK out
shortly. If anyone wants to dive into this before then, I've a copy of
AUHosting that does do this that I can share - just email me
Bill
On 05/12/2003, at 2:35 PM, William Stewart wrote:
We've been discussing this with host apps, and are expecting updates
to implement this in the future
At this stage, the only "host" app that does support this is the SDK's
AudioUnitHosting in Panther.
Bill
On 05/12/2003, at 9:40 AM, Marc Poirier wrote:
So... are there any hosts supporting this yet? I've just tried about
a
dozen different hosts, with no luck in any of them. Or am I just
doing
something wrong in my AU? I'm not sure, maybe I am, I can't tell
since I
don't know which hosts, if any, are supposed to be able to support
this...
If any hostmakers would like to try out a test case of an AU that is
attempting to resize its view, you could fetch RMS Buddy from:
http://destroyfx.org/extras/
You can get it to resize its root pane by Uninitializing, changing the
channel count of its stream format, and then Initializing. In other
words, the view size depends on the number of channels being used,
and the
notification to resize comes from Initialize.
Marc
At 3:32 PM -0700 9/27/03, Bill Stewart wrote:
Some plugins will want to resize their views based on some internal
changes to their parameter state (or other UI considerations), and
we've not been explicit about how this should be handled by either
the
AU or the Host except to say that the AU should *not* resize its
view's
window.
that hosts use to display views), this is definitely required as it
This is still the case (and in fact because of the different
techniques
won't work in a desirable fashion in many hosting situations.
So, the question is how does the AU describe to the host that it's
Carbon view is now a different size than it was previously and thus
the
display space the host is using for it should be resized?
Essentially the mechanism is quite simple.
The AU, when it has to change its view size, should resize the
control
that it returns to the host:
AudioUnitCarbonViewCreate(mEditView, mEditUnit, mWindow, rootControl,
&location, &size, &mAUViewPane);
mAUViewPane, is the control that is created by the AU's View, and is
the parent container of this view. The AU should always maintain the
size of this control (as our Generic View does) to represent the
visual
size of the View the AU will present.
The host then needs to basically do the following (The code below is
quoting some changes I've made to the AUHosting app that now
correctly
deals with this. If anyone wants this rewrite let me know - we'll
make
sure this is in the next release of the CoreAudio SDK):
ResizeControlHandler is a subclass of XEventHandler that handles the
ControlBoundsChanged event in the HandleEventMethod.
mViewPaneResizer = new ResizeControlHandler(this);
EventTypeSpec resizeEvent[] = {
{ kEventClassControl, kEventControlBoundsChanged },
};
mViewPaneResizer->WantEventTypes
(GetControlEventTarget(mAUViewPane),
GetEventTypeCount(resizeEvent), resizeEvent);
A Host can install an event listener for the ControlBoundsChanged
event. Then when the AU needs to change its view size, all that it
does
this view control. (There is one special case the host should look
for
is resize the control. Meanwhile the host will listen for changes to
- and that is that the size of the control is NOT (0,0) - in the
generic UI we're rebuilding the UI completely when the parameter list
changes, so we start again from a control size of 0,0, the resize the
control after rebuilding all of the sliders, etc....)
ie. ALWAYS check that the control's size is greater than 0,0 before
resizing your host window!
When this event is received, AUHosting's EffectWindow will be resized
to allow for the new view size (allowing of course for the top and
left
margins it needs for its controls).
To Summarise:
(1) The AU resizes the view control that it returns from
AudioUnitCarbonViewCreate whenever its display size needs to change
(of
course, when it initially returns this control from the create call,
the control should reflect the view size it requires)
(2) The host installs an event listener for control events of type
kEventControlBoundsChanged on the AU View's parent control that it
receives from AudioUnitCarbonViewCreate. It then resizes its window
reacting in some "set minimum size" manner - resizing when the size
of
appropriately when events of this type are received (excluding - or
the control is (0, 0))
Bill
ps The same general principle applies to Cocoa views too of course -
ie. the plugin should *not* resize the window that the Cocoa View is
embedded in, but should use the Cocoa services in a similar manner as
described above for Carbon views.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
-- mailto:email@hidden
tel: +1 408 974 4056
_______________________________________________________________________
___
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
_______________________________________________________________________
___
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.