Re: Wrapper class for Cocoa Audio Units in Carbon Hosts
Re: Wrapper class for Cocoa Audio Units in Carbon Hosts
- Subject: Re: Wrapper class for Cocoa Audio Units in Carbon Hosts
- From: William Stewart <email@hidden>
- Date: Fri, 14 Aug 2009 14:36:57 -0700
No (to all)
On Aug 13, 2009, at 10:42 PM, tahome izwah wrote:
Which brings up the more general question: is there a way to detect
(in the AU code) whether a given host supports AUs with a Cocoa UI?
Any property that all hosts MUST support that can be polled by the AU?
If not, is there any other recommended way to find out if a host
supports a Cocoa UI?
--th
2009/8/13 Seth Nickell <email@hidden>:
I haven't figured out exactly what to look for (I'm in release mode
on
another project), but I think I can detect if the host is running
Cocoa, and if it is, tell them we don't have a Carbon GUI. Anyone
have
suggestions for what to check to see if our current process is
running
the main Cocoa event loop?
Frankly, even if the running the event loop is because the host is a
Carbon app that has their own Cocoa hosting compat layer, it might be
better to report we are Cocoa, and let the host deal with compat
issues (depending on how they host the views they might do smart
things (ha ha, I wish)).
I tried this technique with detecting the presence of HICocoaView,
and
it works fine. Now 10.4 Carbon-only hosts use their fallbacks for
"this plugin has no ui" (auto-generated ui from parameters), which is
better than crashing spectacularly.
-Seth
_______________________________________________
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
_______________________________________________
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