Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
- Subject: Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
- From: Urs Heckmann <email@hidden>
- Date: Sun, 18 Jul 2010 15:38:34 +0200
Am 18.07.2010 um 14:28 schrieb Motti Shneor:
> In our case --- much of the UI state is only available FROM the AU, AFTER it is initialized (to be painfully specific, our cross-platform UI description system is loaded upon initialization of the AU in the AU). Should a Waves AU be opened, then its related Cocoa view opened when the AU is still uninitiated --- the view must KNOW that and change its appearance accordingly.
Why not move it to the constructor then? - Being able to cope with an open view before initialisation was a requirement for CarbonViews already, basically since 2002. It's nothing new, and everything else has to be considered buggy behaviour.
> our specific implementation cannot currently support more than one view (instance!, not class) per AU.
Then you're not conforming to the standard. I'd recommend to remove the necessity for shared memory and everything will fall in place.
> I must have a way to REFUSE opening a new view instance
As the standard is defined differently there are simply no means to do so.
;) Urs
_______________________________________________
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