We need a referendum... on MEMO...

[John Esak]

> that being said - i would consider changing my stance anyway for a
> design issue not even brought up yet - since <Esc> to save does not
> actually save anything (save for some internal buffer that is pending
> until record itself is saved by some other action) when leaving the memo,
> maybe it should not be used simply for that reason.  you don't want
> users thinking stuff is saved when in fact it is not recorded to
> disk yet.  Does that mean I want <Tab> to leave the field?  I'm really
> not sure.  As suggested, maybe something on <Options> screen can do
> a save/cancel.
>
> the question after all is said and done begs to be asked - if <Tab>
> leaves the memo update field, how does filePro know if you want to save
> the change you made to the 5th word on the 7th line of the 12th paragraph
> or not?  should it automatically assume all should be saved as-is when you
> leave the field, or is it better to have an easy, non-damaging way out
> as there is now?

Hmmm, very good points... I know that I have never cared about the Save
aspect of ESC ESC when leaving a MEMO field because as I noted once a while
back... you can not count on the data being written without an explicit
WRIT... (as you say)... therefore, I started about a year go doind the
following to combat what I thought was a glitch....


    then: memo 4 edit;  write

This way, it doesn't matter if they press BREAK after that or not. It may
not be the best solution because the user may think he will lose his changes
by pressing BREAK... but in my systems, he won't. Lots of times the MEMO or
part of it which was modified does not even appear on the screen, so I
thought/think it better to assure that writes get done regardless.

John