Perhaps the stackFiles property could used to load on stack load rather than
load on demand. Load/unload would certainly be nicer than what we do now which
is check if there is a stack then get the short name and delete when finished
with it.
Sent from my iPhone
> On 25 Jun 2016, at 3:08 AM,
On 06/24/2016 10:08 AM, Mark Waddingham wrote:
Suggests that these are two distinct operations and a 'cleaner' model
would be perhaps to have:
load stack
To load a stack from disk which, as it involves file I/O, should set the
result.
And, furthermore, make:
go stack
Only succeed
not
extricate from? That is the reason for leaving the old way alone.
Craig Newman
-Original Message-
From: Mark Waddingham <m...@livecode.com>
To: How to use LiveCode <use-livecode@lists.runrev.com>
Sent: Fri, Jun 24, 2016 1:09 pm
Subject: Re: Go Card Error Handling
T
> On Jun 24, 2016, at 11:08 AM, Mark Waddingham wrote:
>
> From an error handling point of view, these present two entirely different
> cases.
>
> For operations which you should always expect to succeed *or* can guarantee
> will succeed by a preceding check in code, the
Thanks Dar and Jacque,
That puts it nicely in context. I'd class this behavior, then, as being
for 'HyperCard compatibility'.
LiveCode does have a slightly different model from HyperCard though,
which is why it is perhaps a behavior which should be reviewed at some
point. Indeed, it
In HyperCard 2.2: The Book, the example handler for a "go" to a
non-existent card checks the result and gracefully handles any failure.
Presumably it doesn't throw an error so the stack author can manage
navigation without interrupting the user with a dialog.
The sample handler describes a
In "HyperCard: Script Language Guide" the "go" error message result is
described in the context of file I/O, that is, finding the stack when there is
a "without dialog" clause.
> On Jun 23, 2016, at 11:33 AM, Mark Waddingham wrote:
>
> Hi all,
>
> Whilst investigating a
Hi all,
Whilst investigating a bug this afternoon
(http://quality.livecode.com/show_bug.cgi?id=17873 - which has a moral
attached to it, I'll come back to that) I was reminded that 'go card'
seems to have somewhat inconsistent error handling compared to other
commands which reference