Reassurance re: crashing

[Rob Cozens]

>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.

I think:

* 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 
problems.

* 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 
>positive sense,

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.
-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm

"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)