Re: Resizing AU Views (Carbon)
Re: Resizing AU Views (Carbon)
- Subject: Re: Resizing AU Views (Carbon)
- From: Marc Poirier <email@hidden>
- Date: Fri, 5 Dec 2003 11:40:23 -0600 (CST)
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.