I absolutely understand that. Would it be possible to address my other questions? I *want* to do the work, i simply need a solid path to pursue.
Thanks again, Michael ------- Original message ------- From: Charles Yeomans <[EMAIL PROTECTED]> Sent: 30.7.'07, 19:00 > "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> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
