/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