Reassurance re: crashing
rcozens at pon.net
Thu Jun 6 15:47:00 CDT 2002
>For me, unfortunately, I don't remember what the good or bad habits are.
I'm pretty much in the same boat, Dar. It was just something I worked through.
* A lot of my problems early on had to do with changing a card or
other object I had already created. Maybe things like trying to take
remove properties so they would inherit after-the-fact. Now I get it
right the first time.
* Editing several handlers in a script imported from a HC stack
without applying the changes before changing handlers caused some
* Changing a (relative to the fields I normally work with) large
amount of text in a field (from the properties palette?) two or more
times without saving the stack caused some problems.
* There are sometimes issues resulting from testing a new stack in
the Development UI that are not a factor if it is run from, or as, a
standalone. I know the UI can be turned off from the menubar...it's
just not a habit I've picked up yet.
One other suggestion: become familiar with the Application Overview
window and all it's facilities.
>I think that--except for those cases--Revolution should not crash.
>Ever. So I would not characterize "non-crashing" approaches as
>"correct" approaches, but simply temporary workarounds. This might
>sound like I "demand perfection", and maybe so, but only in a
I agree. And to that end, the better we are at identifying "crash
courses" the quicker the RunRev team can generate fixes to protect us
from ourselves. Once a "crash course" can be verified & replicated,
programming a lock out should be higher priority than new
development. Unfortunately, none of the issues I raised above are
described in enough detail to replicate.
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
More information about the use-livecode