Contents of the ATEDIT.DOC file
ATEDIT: Minimal Clipper version of FoxPro's @...EDIT command
Written by John C. Burkhard
Asta Engineering, Inc.
20251 Century Blvd
Germantown, MD 20874
(C) 1992, 1993 by Asta Engineering, Inc. All Rights Reserved.
License (in simple terms): You didn't write it, you didn't pay
for it, so you can't sell it.
You can give it away.
You can include it as part of a program you write, regardless of
whether it is for personnal or business use, but you can't charge for
this code. You're free to do what you want with your code, though.
Any changes or enhancements you make to the software are bound
by this license.
This software is provided free of charge on an "AS-IS" basis.
Asta Engineering, Inc. will not be liable for any damages whatsoever
including direct, indirect, consequential or other, resulting from
the use of this software. This software is provided without warranty
of any kind, including but not limited to WARRANTY AGAINST DEFECTS,
WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, and WARRANTY OF
MERCHANTABILITY. So there.
How to Use:
ATEDIT is a set of routines and a User Defined Command which
implements a limited form of FoxPro's @...EDIT command. The command
@ , TO , EDIT
[ COLOR ] [ SCROLL ]
and specifiy the upper left coordinates of the
edit window, while and specify the lower right
coordinates. is the character variable to edit.
If specified, provides the color attributes for the edit
window. If ommitted, @...EDIT uses the same color combinations as
used by @...GET.
When included, the SCROLL keyword allows the edit window to
scroll. In scroll mode, the window behaves like a normal editor
In a non-scrolling edit window, the field behaves much like a
normal field. Pressing the up arrow while on the first line of the
field will take the cursor to the previous field, while pressing the
down arrow key while in the last line of the region will take the
cursor to the next field. Page Up and Page Down within a
non-scrolling edit window behave as they would in a normal field.
In scrollable fields, you may only exit the edit mode by pressing
Ctrl-END (Ctrl-W) or ESCape (Ctrl-Q).
Because of the whacky way in which Memoedit() works, and because
of the limits in the Get system, you should be aware of a few things:
- LastKey() will always return K_CTRL_END when exiting from the
@...EDIT reader function (except of course when it doesn't). It's
the only way I could see to get MemoEdit to behave the way I wanted
it to. Note this only applies to non-scrollable fields. Scrollable
fields work correctly.
- Because LastKey() returns K_CTRL_END regardless of the actual
key you pressed to exit the field, well... You can probably see that
LastKey() is pretty useless for figuring out how the user exited the
If knowing the key used to exit the read is really important to
you, unless you want to modify the get system, you're out of luck.
I personally would love to see a small footprint fast editor
with the same capabilities as memoedit() but with the flexibility of
I'd appreciate any comments, thoughts or suggestions about this
code. It's not too sophisticated because I didn't need it to be for
my application. If you can suggest any changes (or better yet,
contribute any changes) let me know!