re: MOVE VS COPY

[Joseph Hoffner <hoffner@westshore.cc.mi.us>]

>What if, when I go into the copy menu, I *ignore* the RectArry and CircArry,
>and just give it two points for distance, then select vie EGAF... will it
>copy??  Could it be possible that copy works like move and copy except it
>doesn't have a drag??  It certainly seems that way from the book.  Maybe
>this has been much ado about almost nothing?
>
>Carl Steidel

Carl,
YES, the basic functions work exactly the same. However, it is the lack of
the DRAG function in the COPY menu that I have been eluding to from the very
beginning. My problem is as follows:
        I often DRAG items around the screen and visually place them where
desired. When COPYING a single item to many locations throughout the drawing
I must use MOVE\DRAG\ANDCOPY to do so. It is the only option. I may return
to this function many times before I am done using the ANDCOPY toggle. Much
later, I return to MOVE and forget to check the ANDCOPY toggle. Therefor,
creating a much undesired COPY instead of a standard MOVE. When it consists
of an entity or two it is easily fixed in seconds. When it is the
realignment of a saved perspective view it is a very tedious,
time-consuming, and potentially disasterous error.

Again, a better way to keep tabs on the position of the ANDCOPY toggle would
greatly improve this situation, but the addition of DRAG to the COPY menu
would be a permenant fix. With this added function I would no longer have a
need for the ANDCOPY toggle in the MOVE menu and would probably never use it
again. (whether it remained there or not) This would create much greater
effeciency by not only eliminating the above described error completely but
also eliminating the need to do a 'quick check' of ANDCOPY prior each and
every MOVE operation.

And that...to the relief of all I am sure...is my final word on MOVE\ANDCOPY.

Joe Hoffner
hoffner@westshore.cc.mi.us

PS. I would, however, like to hear some comments directly from MCS on this
issue.