It's only a problem when the input splitters from the DataTools are added back in (from the github src). So, stock DataTools=OK when being loaded from bundle.
So, maybe I'm finding another reason why that wasn't a good implementation (re: my nagging about adding those back in). -gt On Apr 19, 2012, at 11:56 PM, George Toledo wrote: > Err, sorta correcting that: > > This is a apparently a problem specifically with something I'm doing and > DataTools.plugin from Kineme. "loadPluginsInFolder" method also results in a > crash when I have that plugin in my bundle. It may very well be that > loadPluginAtPath is fine too (but it does trigger a warning). > > I'll dig into the causes more in the future, but I want to clarify the > previous post. Sorry for not sussing that out more before posting. > > -gt > > > On Apr 19, 2012, at 11:37 PM, George Toledo wrote: > >> So, to answer my own question, sort of, or make it a moot point. After >> looking at the interface for the QCPatch registry more: >> >> Using loadPlugInAtPath will work, but only "sort of". If there's a duplicate >> QCPatch on the system, the app may crash. (Sort of unfortunate.) >> >> Specifying your location via nsstring, in my case, the resourcePath: >> >> NSString *pluginsPath = [[NSBundle mainBundle] resourcePath]; >> >> and then using: >> >> [QCPatch loadPlugInsInFolder:pluginsPath]; >> >> Apparently will take care of crashing when the QCPatch is in your bundle and >> also on the user's install. Also, it doesn't signal an exception in Xcode as >> long as you setup an interface in the header, so it makes me a feel a little >> more warm and fuzzy about it than the loadPluginAtPath. >> >> It doesn't really quite take care of what I want, which is to "not load" a >> QCPatch from a user's install if it exists in my bundle, but load other >> QCPatches that exist. Browsing through the adc resource on bundle/plugin >> loading gives me some ideas about it. >> >> -gt >> >> On Apr 19, 2012, at 2:34 PM, George Toledo wrote: >> >>> >>> It seems like this had been covered on-list before, but I can't find the >>> post (or maybe it was just mentioned, but without resolution). >>> >>> Is there a preferred method of having my app "not" load specific QCPatches? >>> I don't want to block loading of all QCPatches - it's convenient for this >>> project for the app to load QCPatches from the normal folder locations. >>> It's just that it seems as though if I load a QCPatch from the resource >>> bundle of my app, and it's already existing on a user's install, that the >>> app crashes on start. If the QCPatch is just in one place or another, >>> everything is OK. >>> >>> Right now, I'm loading QCPatches like this: >>> >>> NSString *pluginPath5 = [[NSBundle mainBundle] >>> pathForResource:@"AudioTools" ofType:@"plugin"]; >>> [QCPatch loadPlugInAtPath:pluginPath5];//hmm, warning but it does work >>> >>> >>> So, I know that one can load all of the QCPatches in the resources folder >>> in one shot, but I'm listing them out one by one. I've tried the method of >>> just loading all of the QCPatches in my resources folder instead of >>> explicitly listing each one - that works fine too, but still has the "app >>> crashes" problem, if a user already has the QCPatch installed in one of >>> their Quartz Composer Patches folders. >>> >>> I think I could go down a route of having the app check to see if >>> particular QCPatches exist at all three possible folder locations, and then >>> have my app load them, if not, but I'm not sure if that's the best route. >>> >>> Thanks for any thoughts. I realize this is private API, so I'm not >>> necessarily expecting support, but I'd like to have it be a little slicker >>> than requiring a user to install the QCPatches in their /Library or >>> ~/Library, or make sure that they *aren't* installed (not really a >>> possibility). Right now I just have the needed QCPatches setup in a DMG >>> with an alias to the /Library folder for the user, but it seems slightly >>> cheesy to do that when I'm loading some needed QCPlugins from the app >>> resources bundle already. >>> >>> -gt >> >> > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
