That's what happened to the person I'm helping. He's not a sophisticated
coder and needed someone else to write a basic openstack handler a few
years ago. He's been tinkering with the stack now and then and building new
apps occasionally as it changed. He called me, very distressed, and was
ready to throw out LC entirely. He'd been trying for a week to build the
app and was getting infinite repeated error dialogs that couldn't be
dismissed. The error dialog was empty so there was no clue what was wrong
and clicking the Script button did nothing.
He had contacted support but couldn't afford the rate they wanted to debug
the problem. He had no idea why the build suddenly failed all of a sudden.
He's a paying Indie customer and LC would have lost him.
So yeah, there's repercussions. I do understand the choice the team had to
make, but most of us were used to the old way and had already accommodated.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On September 19, 2018 6:22:05 PM Graham Samuel via use-livecode
<use-livecode@lists.runrev.com> wrote:
I am very late to this conversation, but does this mean that a very naive
user, devising a simple app that is going to end up as a standalone, will
suddenly be plunged into weird unguided coding issues just because the code
contains ‘preOpenStack’ and similar handlers, maybe even a ‘Startup’
handler (I use those a lot myself)? If this is true, then I agree with
Richard that LiveCode has suddenly got a loss less attractive in its
central function - the creation of software that runs on the developer’s
chosen platform(s). Just tell me I’m wrong.
Graham
On 20 Sep 2018, at 00:47, 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
