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@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
>
_______________________________________________
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
