Re: Identify when a user attempts to turn on "Allow cell drag and drop"

From: JE McGimpsey (jemcgimpsey_at_mvps.org)
Date: 11/19/04 

Date: Fri, 19 Nov 2004 07:24:52 -0700

Well, in part it's a training issue. But it's also a design issue. Since
I can't think of any way to make it foolproof (fools getting more clever
all the time), perhaps one way would be to protect the work***
(allowing filtering perhaps), and putting a button on the *** that
removes that protection, disables drag and drop, and throws up a message
box saying something like "Drag and Drop has been disabled. in the
interest of data integrity, please don't change the Drag and Drop
preferences while editing this workbook". I'd use the
Workbook_SheetSelectionChange event to disable d&d every selection
change as well.

That way, someone would have to deliberately violate your restriction in
order to use d&d.

In article <#sRJhFdzEHA.2036@TK2MSFTNGP12.phx.gbl>,
 "Alan" <alan@alan.alan> wrote:

> The workbook is used to track workflow in a services business.
>
> Client name, some other client details relating to the type of job,
> date in, date started etc etc through to completion.
>
> Users often filter the list to only show their clients, but we were
> getting problems where a user 'dragged' or 'copied' a date (say) from
> one row down through what appears to them as being only their clients,
> but in fact also contains hidden rows with other clients, thus
> creating a data integrity issue.
>
> We disabled D&D and C&P to stop that happening.
>
> Of course, we could just say it is a user training issue, but if
> someone forgets just once, and saves the file, then everything can go
> to pieces quickly. If they do it accidentally and know that, then
> they
> just don't save those changes.
>
> The risk was such that we decided it would be best to disable that
> functionality.
>
> However, some bright sparks have been turning it back on. That is
> okay, and they say 'we know what we are doing', but one of them did
> forget, caused some damage, and didn't know it. In fact, they won't
> even notice of course - it is someone else's client workflow data that
> is damaged.