If what you're asking is if two different sets of scripts without source code could be integrated to run and be active for the same application, I can think of one way to do this, but without access to the source code, it's always going to be an iffy proposition. The basic idea would be to combine the jkm files for the two sets of scripts. If there are key conflicts, you'd have to make reassignments to eliminate these. You'd create a script file for the application that "Uses" the two jsb files. However, there's no guarantees this would result in properly functioning scripts that play nicely together. Special attention would be needed to handle shared event functions and if the two jsb's happen to declare global variables with the same name, you'd probably just be plain out of luck. Plus there'd be all the difficulties of reverse engineering and figuring out how to meld the scripts in order to make them play nicely together. For simple script sets, this probably wouldn't be a major problem, but for complex script sets, it's likely that one or both will inadvertently stomp on the other at times. By far the best way of achieving this would be to have the two authors colaborate on making their scripts coexist harmoniously as pointed out by Chris. Mind you, this would make the task of updating the scripts while maintaining compatibility somewhat of a headache for the two developers. I've only made some general comments here, as I am familiar with neither the scripts nor the applications under discussion. However, I am pretty certain that, provided there were sufficient will on the part of two script developers, a framework could be established whereby scripts could be made to work together without the need to have access to each other's source code . For a partial example of this, you need look no further than the Hotspot Clicker scripts which have been integrated into a number of other script sets with fairly little effort and the source code is not strictly required for this, merely knowledge at an API kind of level. Whether it would be worth the time and effort for two developers collaborating to do this kind of thing is another story altogether. Reading over what I've written, I'm not sure that anyone'll be able to follow me, but here it is anyway. Hopefully someone finds it useful. Cheerio, Andrew. On 9/01/2012 4:31 PM, Chris Smart wrote: > Dave, native Keys won't be integrated into CakeTalking unless > CakeTalking allow it, make their source code available to the guy > who makes Native Keys. > -------------------------------------------------- > CTS MASTERING: PROFESSIONAL MIXING AND MASTERING! Clear True Sound: > www.ctsmastering.com -- > > Always have your stuff when you need it with @Dropbox. Seamlessly > share with your friends and colleagues. 2GB account is free! > http://db.tt/bQ2GuIt > > __________� > > View the list's information and change your settings at > //www.freelists.org/list/jawsscripts > > > __________� View the list's information and change your settings at //www.freelists.org/list/jawsscripts