dunbarx wrote: > It is academic to me why this must be, especially since I thought I > had learned something new and important in that one must load third > party externals into the contents folder of a standalone package by > hand. In my case, doing this had no effect at all. I assume that this > method (the "ordinary" method) gives one a "relatively" referenced > pathname to ones external. The authors actually said they did not > know how to write such a "relative" pathname. > > Is this of interest to anyone but me?
You're not alone. I find working with externals finicky, delicate, and frequently troublesome.
I guess I never got over the simplicity of using externals in SuperCard and HyperCard, where they were embedded in the stack file and instantly usable with no further mucking about.
With LiveCode, one must be very careful with paths to externals. Sometimes relative paths can work, sometimes not; sometimes including references to both Mac and Win externals will work without issue, other times it causes conflicts; and always one must be mindful of the timing of their loading relative to when and how you'll use them.
In a perfect world we've be able to just set relative paths for each platform we'll need them on, and the engine would figure it out from there.
As it is, I've had to write a handler which checks for the externals files, branches by platform to set the externals property for the one the app is currently running in, and when all those steps work without issue I get the additional functionality.
Sometimes I miss SuperCard. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com LiveCode Journal blog: http://LiveCodejournal.com/blog.irv _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
