Hi Michael,
I was able to create a resize-able CocoaView for AU recently. In previous years it did seem difficult/impossible, but maybe hosts have updated something (as part of the Carbon-to-Cocoa UI migration?) or Apple's framework has been tweaked to allow it by default for certain types of windows/views (not sure which OS X version is the boundary, I am just speculating here). Here is a brief outline of how I did it. I am sure there are other ways (I guess you probably already know this first part cold, I am just hoping this gives others some context for future reference):
1) I implemented the UI as a bundle included within the outer AU bundle/component. This involves all the usual plumbing with the kAudioUnitProperty_CocoaUI and AudioUnitCocoaViewInfo property getters and bundle management.
2) The bundle's main entry point is implemented via the uiViewForAudioUnit:withSize factory method from the AUCocoaUIBase protocol/interface. In that factory method I return my custom view. Then, at run-time, I take the host-given inPreferredSize argument into consideration, but sometimes I just ignore it (depending on the size given). I find the variance of this value to be kind of large and _sometimes_ not always "honest", it really depends on the host.
3) Finally, in my custom view, I override the viewDidMoveToWindow method like so:
- (void)viewDidMoveToWindow
{
[super viewDidMoveToWindow];
[[self window] setMaxSize:CGSizeMake(MAX_WIDTH, MAX_HEIGHT)];
[[self window] setStyleMask:[self window].styleMask | NSResizableWindowMask];
}
This works really well for me, especially when combined with NSLayoutConstraints. Using that API your view (and subviews) can automatically adjust proportionally to the dynamic size of the window set by the user, if you choose to code it that way. I remove elements that can no longer fit when the window shrinks, and add new elements as the window size expands, for example.
Caveat: I do not know if any hosts directly embed the view you return from the factory method into their main window. On the hosts I have tested this view is typically opened in its own new window, so calling the above methods on that window seems safe. I assume that the inPreferredSize hosts would be more of a requirement than a "preference" if the hosts were embedding your view into their own main window, but again, I am just speculating on that. There may be a way to program this size setting more defensively, I haven't explored it yet.
As far as making the main view a subclass of NSScrollView, I would consider making the returned view a simple container view that contains an NSScrollView as its main subview, and nest everything from there. You should get the same behavior, but it may be easier to reason/debug from a parent container view... or not worth the extra overhead... just a suggestion, feel free to ignore.
--Christian