What about a front script for the build process that would intercept and discard these messages? Could be inserted just before each action that used to be protected by lock messages (close/open stack).
Thanks, Brian On Sep 19, 2018, 11:41 PM -0500, J. Landman Gay via use-livecode <use-livecode@lists.runrev.com>, wrote: > I do understand the dilemma and I can adapt. But to be fair, an > uninitialized variable doesn't require a restart of the IDE. It's possible > to script around that too, it's usually a one-liner, and doesn't have to be > inserted in as many places. > > But what mainly concerned me was how it affected someone who couldn't > explain the change and the inexplicable cascade of errors, and was > frustrated enough to leave the platform behind. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > On September 19, 2018 5:49:20 PM Monte Goulding via use-livecode > <use-livecode@lists.runrev.com> wrote: > > > > On 20 Sep 2018, at 6:18 am, Richard Gaskin via use-livecode > > > <use-livecode@lists.runrev.com> wrote: > > > > > > Building a standalone is the whole point of the process of developing with > > > LC, and now that it's so disruptive it kills the joy of choosing LiveCode. > > > > > > For more than a decade I've believed making the SB into a separate process > > > would be a good idea. > > > > > > It's no longer a good idea. It's now a necessity. > > > > Unfortunately we are caught between leaving the stack in a state where any > > local variables that are meant to be initialised are unset or letting the > > engine do its thing when the stack reopens and send messages that allow > > those initialisations to occur. The latter, while a big change, was > > considered the lesser of two evils because at least it allows you to code > > around the situation rather than just ending up with a stack in a state > > where you need to quit and restart the IDE. > > > > Ideally, yes, standalone building (at least the parts that manipulate the > > open stacks causing them to need to be reverted) would be a separate > > process. > > > > Cheers > > > > Monte > > _______________________________________________ > > 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 > > > > > _______________________________________________ > 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 _______________________________________________ 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
