circa 12/21/04 2:40 PM, "Pete Gontier" <email@hidden> wrote:
>>> Can I (assign an AMS icon to a device) as an application as opposed to a
>>> driver plug-in?
>> Yes. Most of what AMS does can be done by any application that wants to, and
>> more -- AMS protects certain propeties that are supposed to only be set by
>> the driver, but that's not enforced by the server. I'd discourage people from
>> going too deeply into this (e.g. playing around with connections) but in the
>> case of a hardware utility that wants to slam its own icon onto a driver,
>> that's a perfectly good reason. Just set the property on the device.
> Woo hoo. I already have a helper app lying around.
OK, it's working. The app unconditionally sets the property whenever it sees
a relevant device. The app builds the absolute path when starting up to
reflect where in the file system the program has found itself, which changes
fairly often during development, so this strategy is good for me. However, I
can see how this would not be good for users, because AMS allows them to
override the icon I've provided. The next time my helper app sees the device
(which is fairly often since I dispose my MIDI client after 5 seconds of
inactivity and bring it back up when needed, but in any case this will be at
least once a boot), it will override the user's choice, which is likely to
surprise them. I would either like to prevent users from being able to
choose another icon or I would like to be able to detect when the user has
overridden the icon I've provided. Are there properties which can help? If
not, I have a fallback idea, but I'd rather not resort to it because it's
likely to result in confusion during development.
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