"Exactly" + screenshots would take a fair amount of time to put together for you. You might get a better response by looking for someone to whom you can outsource this part of your project.
Charles Yeomans On Jul 30, 2007, at 6:47 PM, Michael Williams wrote: > Alright, but I'm still a bit sketchy on actually placing the > "framework". Basically what I want to know is where *exactly* > (screenshots might be helpful) do I place all files at any point in > time so as to both test and distribute? And, why is it necessary to > have different spots? > > Also, a bit of a side question as I lack sufficient knowledge to ask > the proper question, but what are the general mechanisms by which to > extract existing functions from C-source? How does Visual Studio vs > XCODE vs GCC handle "method extraction"? "Method extraction" meaning > a nice sidebar (e.g. Eclipse), or printout of existing functions/ > methods. It would be nice to have a handy-dandy list so as to look > at what portions I wish to Declare. > > Thanks, > Michael > > On Jul 30, 2007, at 6:19 PM, Dave Addey wrote: > >> I do this in a dual way - using one location for debug, and another >> for the >> built app: >> >> #if DebugBuild >> Const kHIDLib = "@executable_path/../../../libHIDUtilities.dylib" >> #else >> Const kHIDLib = "@executable_path/../Frameworks/ >> libHIDUtilities.dylib" >> #endif >> >> Declare Function HIDGetFirstDeviceElement Lib kHIDLib >> (inDevicePtr as >> integer, inElementTypeMask as integer) as integer >> >> When I have built the final app, I copy the dylib inside the bundle >> and the >> non-debugbuild line above finds the dylib. When I am running in >> debug, the >> code above looks for the same dylib, *alongside* the debug app. >> This means >> I don't have to build the app to test every time, and can still run >> in RB's >> debug mode. >> >> Dave. >> >>> From: Norman Palardy <[EMAIL PROTECTED]> >>> Reply-To: REALbasic Plugins <realbasic- >>> [EMAIL PROTECTED]> >>> Date: Mon, 30 Jul 2007 11:28:30 -0600 >>> To: REALbasic Plugins <[email protected]> >>> Subject: Re: Incorporating existing C/C++ libraries into an RB >>> Project. . .? >>> >>> >>> On 30-Jul-07, at 11:16 AM, Michael Williams wrote: >>> >>>> Gotcha, >>>> >>>> So you're recommending going the "dylib" route as opposed to the >>>> plugin route? What kind of recommendations have you for actually >>>> distributing the "dylib"? Someone mentioned actually placing the >>>> "dylib" in the RB package, I'm not terribly familiar with that >>>> process, nor how to reference a self-contained library. >>>> >>>> Michael >>> >>> >>> you can use a "special" name for a dylib in OS X that permits you to >>> locate it relative to the actual executable >>> >>> instead of >>> >>> Soft declare sub/function name lib "lib name" .... >>> >>> use >>> Soft Declare Sub/function name Lib "@executable_path/../ >>> Frameworks/lib name" .... >>> >>> and then in the OS X version you copy your dylib into the FrameWorks >>> folder in the package _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
