/appl/fp/termcap file

Fairlight fairlite at fairlite.com
Fri Oct 28 13:56:26 PDT 2005


Y'all catch dis heeyah?  Enrique Arredondo been jivin' 'bout like:
> 
> In that remote system if you *clerk* a file and do a ADD records then type 
> anything in any field and then hit the backspace to see if you can do a 
> destructive backspace, did it delete the preceding character or just jump 
> left leaving the character ?
> 
> That's the problem I'm having and I also have the kb=\177 in the fp's 
> termcap file.

It's non-dstructive.

That said, I worked with fP directly for 2.5 years as well as on and off
since then.  I remember what the exact difference in *cabe is:

If you hit backspace while you're in overwrite mode, it is non-destructive,
and simply backs you up without deleting the character destructively.
(Okay, that's redundant!)

If you turn on insert mode, backspace becomes destructive.

I always keep insert mode on in *cabe.  I can't stand the default.

However, I know you're specifically saying *rclerk.

The default of *cabe appears to be the -only- way *clerk acts, however.
I can't help but wonder (especially due to how *cabe works) if this isn't
by design.  FWIW, a lot of database/data-entry software was like
that--with non-destructive backspacing.  Drives me nuts too.  I think even
CICS was like this, though I haven't touched that since 1992.

I wouldn't dink with the termcap, probably.  There's got to be a way to
write a field input routine that traps all the special keys correctly and
pushes them, but if it sees you hit backspace, pushkey that -and- then F2.
That's probably what I'd pursue if I were looking at it.

mark->
-- 
There is no "I" in TEAM.
This would be the primary reason I've chosen not to join one.


More information about the Filepro-list mailing list