Aaaah, ok ;) thanks. But now - will this actually help? I mean this
basically takes one class and creates another class from it realtime. But
if plugin A is created, then plugin B is created (which takes classes from
A unfortunatelly), wouldn't it also create the new classes from the A
superclasses? Because I see no reason why it should do it a different way.

Vojtech


2012/9/6 Olivier Tristan <o.tris...@uvi.net>

> check the git version.
> This has changed recently.
>
>
> http://juce.git.sourceforge.net/git/gitweb.cgi?p=juce/juce;a=blob_plain;f=modules/juce_core/native/juce_osx_ObjCHelpers.h;h=6f643705923e6a0319ddcb7b4dd616a303500df7;hb=refs/heads/master
>
>
> On Thu, Sep 6, 2012 at 10:58 PM, MeldaProduction <i...@meldaproduction.com
> > wrote:
>
>>   Create cocoa class at runtime
>>>>
>>>> You can check how this is done in Juce, especially in the AU wrapper.
>>>> http://www.rawmaterialsoftware.com/juce/
>>>>
>>>> HTH
>>>>
>>>
>>> Thanks. One trouble - I checked and I didn't find any runtime cocoa
>>> class creation - they seem to have special Cocoa views for AU. But I'm
>>> worried about this, because even if I'd create special classes for all
>>> interfaces (which is sick, but ok...) by subclassing my default view class,
>>> what is the odds that the god damn system will use the class from the first
>>> loaded module anyway, they will be there too obviously. Any ideas?
>>> Or can you point me out into Juce, where the thing is supposed to be?
>>>
>>>  Vojtech
>>>
>>>
>>>  check juce_osx_ObjCHelpers.h, ObjCClass class and its use
>>>
>>
>> Thanks, but I must be missing something. I'm looking at Juce 2.0 and I
>> found nothing that would even closely remind runtime cocoa class creation.
>> juce_osx_ObjCHelpers.h only contains some postfix creation, similar to what
>> I use in my plugins to ensure plugin A won't take classes from B. But I
>> meant a different problem - in my case plugin A is actually the same as B,
>> same binary, same resource, everything... But one is used as VST plugin,
>> the other as AU plugin. Then the names of the classes are obviously the
>> same, so I just need to ensure binary A will take classes from A despite
>> they are also in B.
>>
>> Vojtech
>>
>>
>
>
> --
> [image: UVI] <http://www.uvi.net/>
> Olivier Tristan | Research & Development
> o.tris...@uvi.net <o.tris...@ultimatesoundbank.com>
>
> [image: Facebook] <http://www.facebook.com/UVI.Official> [image: 
> Twitter]<http://twitter.com/UVIofficial>
>  [image: Youtube] <http://www.youtube.com/user/UVIofficial> [image:
> SoundCloud] <http://soundcloud.com/uvi-official> [image: Blog 
> UVI]<http://blog.uvi.net/>
>
>
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to