Re: Standalone issue

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Standalone issue

Geoff Canyon via use-livecode
Thanks to both Brian and Jacqueline

Of course, no one's code is perfect and errors do occur, particularly in the early going.  Interesting that this "fix/issue" deals with an error occurring *in* the standalone as the standalone is being built.

Anyway, if there is an error which the standalone build "exploits" because of this condition, GOOD!  I'm sure we hope for (but don't always receive) an accurate cause of errors by ANY development system.  So, I'm good with the standalone "causing" *any* error if there's an error in my actual code.

I appreciate the explanations.

Douglas Ruisaard
Trilogy Software
(250) 573-3935

>
> On 10/27/18 10:26 AM, Douglas Ruisaard via use-livecode wrote:
> > If that's true then there's (sigh!) one more reason to stay away from LC v9... but I really don't
> understand the reason why this is necessary in the first place.  I've never had a standalone fail with
> a "can't find stack" error:
>
> If your builds are going smoothly you don't have to change anything. Try
> it in LC 9 and see. The problem only occurs if any "open" or "close"
> handlers do something that interferes or throws errors.
>
> > So, does this situation only occur for the first standalone build?  Not the second time?  What is
> implied should be done if one of the conditions in the function is false? .... very confusing!!!
>
> A "can't find stack" used to occur the first time you build during any
> one session. The updated handler check fixes this so you don't need to
> worry about it any more.
>
> >
> > I guess I was looking for something more specific about where to put this "fix":
> >
> > e.g.
> >
> > In an openStack call, you'd put this ... where?  At the end of the code just before the "end
> openStack"? (that's where I put it):
> >
> >       if isBuildingStandalone() then
> >            exit openstack
> >       end if
>
> The idea is that this fix will prevent the handler from executing at
> all, so it needs to be at the very front of the handler, right after the
> "on <handlername>" line.
>
> > My question, then, is do I have to have a similar "if isBuildingStandalone()" call in all the
> "opens" and "closes" you list (and others) and do I "exit" the call if isBuildingStandalone() returns
> "true"?
> >
> > WOW! ... if THAT's needed then I can't imagine anyone editing all of their code to do this!!!
>
> Yes, that's what the additional lines do -- exit the handler before it
> can run. And I agree that this is an issue for some apps. The problem it
> tries to solve is retention of script local variable values, as well as
> preventing unnecessary handlers from running. But I'd rather
> reinitialize things when necessary than to add extra lines to so many
> engine messages.
>
> I'd be happy with a simple toggle that lets me turn on lockmessages
> before building. I've been accomodating that behavior for years.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode