Standalone problem (solved?)

[Peter Haworth]

This is all quite timely for me as I just started, reluctantly, to try to
figure out how to write an external.  It's discouraging to hear that, even
if I get through figuring out how to make an external from the incomplete,
out of date lessons on how to do it, there are various other hurdles to
overcome to actually use them reliably.

I managed to make it through the tutorial as far as building the sample
external, at which point the lesson says a new stack should pop up in the
IDE.  It didn't.  The lesson gives no clue as to how to proceed from that
point.  I'm fortunate in being assisted by a member of this great community
off list, but still struggling.

My efforts are directed at trying to get my app into the Apple Store.  It's
pretty clear that checking the MAS receipt is going to require externals.
 There's a commercial product available to generate a C function to check
the MAS receipt but it needs to be made into an external and since RunRev
support are not able to tell me if or when they will be providing any help,
I don't have much choice but to try and muddle through the externals
process myself.  And then there's sandboxing.

Pete
lcSQL Software <http://www.lcsql.com>



On Tue, May 22, 2012 at 7:28 AM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

> 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<http://LiveCodejournal.com/blog.irv>
>
>
>
> ______________________________**_________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode>
>