Supress Standalone Builder Warnings

[Bob Sneidar]

Hi Curry. Thanks for your help and Jacque as well. 

I did as you say, in card 1 of the splash stack (which is the stack I build from because I do not have the need to modify it runtime) I have this code in the card script: 

on closestack
   --- curryk 2020 no-purge LC build:
   if the environment is “development" then
      lock messages
      --- and only if add'l loaded MAIN stacks with issues:
      try
         save stack "Forms Generator"
         delete stack "Forms Generator"
         # delete stack "XYZ" --- etc
      end try
   end if
end closestack


The result is the first time I build everything goes smoothly (as it always has.) The SECOND time I build I get an alert dialog for every stack that is a behavior of something in the Main Stack or that I started using (library I guess). 

The standalone Builder opens COPIES of these stacks to add to the standalone, then LEAVES THEM OPEN IN MEMORY. THAT is the heart of the matter. The SB ought not to do that! (I’m talking to you LC devs.) 

I suppose I could enumerate all of those and then just have code that statically closes each stack. That is probably what I will do. 

Deleting the main stack does not delete the COPIES of those library or behavior stacks. 

In summary the problem is not what is open when I go to build. The problem is what is open after I build.

Anyway, my thanks again for everyone who offered a suggestion on how to resolve this. Sometime the brute force workaround is the only workaround. 

Bob S


> On May 6, 2024, at 4:48 AM, Curry Kenworthy via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 
> Bob:
> 
> > Yes but as I mentioned, that did not work for me.
> 
> You used something DIFFERENT (a partial implementation) so different results -
> 
> That’s fine; it’s just not this particular workaround! 😊
> 
> I think you misread a code comment, now edited for clarity....
> 
> > I still got the two messages after the first build,
> > then messages for ALL my subsequent stack files
> 
> That’s what the last part does: close (‘delete’) any ADDITIONAL problematic main stacks in memory -
> 
> (NOT the build stack again!) - to avoid subsequent dialogs.
> 
> Then ... smooth building, here, ever since.
> 
> Your auto detection effort would be very useful, but just manually identify the SPECIFIC problem stacks, per the dialogs – and ‘delete’ the MAIN stacks thereof in the code.
> 
> If more than a couple main stacks to delete, I would use repeat with a test or try. Likewise, the isBuildingStandalone() function from Panos could provide a more specific closestack trigger if needed for splash stack, but I haven’t tried it in this workaround.
> 
> Whether behaviors or other issues could ever require an extra step, obviously we CAN enjoy the same build experience as pre-2020 SB, by simply using the same techniques! Just as I have.
> 
> > [Standalone Builder] ought to just work out of the box
> 
> YES! Reported (again) to LC yet?
> 
> It is a bug/defect, but that was denied at the time.
> 
> Best wishes,
> 
> Curry Kenworthy
>