Trap Paste event

[Paul Grossman]

Hi, how can I trap the Paste Event on a form, as well as being able to
detect which was the current field.

TIA
Paul.

 

[Allen Browne]

There's no "paste" event, and a Paste can occur in many ways, e.g. keyboard
(Ctrl+V), right-click, toolbar, menu, ribbon (A2007), or code.

It is therefore not a simple thing to trap. Keystrokes and right-clicks can
be trapped with the events of the form/controls, and you could design custom
menus/toolbars/ribbons. But it might be easier to re-think why this is
needed and see if there is another approach.

 

[Tom Wickerath]

Hi Paul,

Hi, how can I trap the Paste Event on a form....

What are you trying to accomplish? Are you trying to prevent a person from
pasting information from the clipboard?

...as well as being able to detect which was the current field.

Screen.ActiveControl.Name can be used to detect the name of the active
control. This is probably safer than attempting to detect the field, using
Screen.ActiveControl.ControlSource, since not all controls have a control
source. For example, this produces a run-time error with a command button
selected.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[Paul Grossman]

Hi Alan and Tom:

The reason why I need to look into trapping paste is because I am
maintaining a database application using access as the platform for the
"front-end" forms and reports for a client and among the features that app
has is that they collect their customer's email address. Currently the app
makes the user confirm the email address (re-type the e-mail address a
second time) but the new requirement is to do the confirmation while
preventing the user from doing a copy and paste of the email address into
the field the 2nd time.

So I need to make an enhancement to require a 2nd typing of the e-mail
address (to confirm) but prevent the user from "re-typing" the email address
by just copy and paste the originally typed email address.

I haven't yet found a way to detect if someone typed something into a text
box or whether they pasted something into a text box. But that's what I
need to do - detect whether someone typed the data into a text box or
whether they pasted something into a text box.

Again, the motivation for doing this is because my client specifically
requested that I do so.

If you have any more thoughts on how to detect how data was entered into a
textbox field, please let me know...

Thanks again for your help. I greatly appreciate the time you took to share
your thoughts with me so far.

Paul.

 

[Paul Grossman]

Btw Allen - sorry for the previous misspelling of your name.

Paul.

 

[Allen Browne]

[snip]
... prevent the user from "re-typing" the email address by just copy and
paste the originally typed email address.

Hmm. One approach would be to attempt to frustrate all the ways a paste
could occur, including:
- destroy Ctrl+V keystroke in KeyDown
- custom shortcut menu (for right-click) without paste.
- custom toolbar (runs code for paste that checks for this case)
- custom menu (like toolbar)

Another way might be to declare a form-level variable (in the General
Declarations, at the top of the form's module) to track the number of
characters in the control's Text property. Set it in its Enter event. In the
control's Change event, if the .Text is changing more than a character at a
time (or possibly 2 for some code pages), then the change was triggered by a
paste, so Undo the control.

I haven't followed through on that idea, but there should be a way to get
that to work. It seems safer to me than assuming you've trapped all the way
a paste could occur.

 

[Tom Wickerath]

Hi Paul,

How about using the function shown in this Knowledge Base (KB) article to
send a zero length string ("") to the clipboard?

(ACC2000 How to Send Information to the Clipboard
http://support.microsoft.com/kb/210216

I added the parentheses around the ACC2000: part, because this KB article
should apply equally well to other versions of Access. You might try "zeroing
out" the contents of the clipboard in the On_Enter event procedure for both
text boxes. I think this would work, because if there's nothing left to paste
then you shouldn't need to concern yourself with disabling Ctrl V, the edit
menu, etc.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________

 

[Larry Linson]

Btw Allen - sorry for the previous misspelling of your name.

That's OK, your penance is to henceforth call him "Sire" or "Your Imperial
Majestic Highness", although with his inner circle of courtiers, I've heard
he is comfortable with his nickname "Majesty." <GRIN>

 

[Allen Browne]

That's OK, your penance is to henceforth call him ... <GRIN>

Larry, watch out: I'll get you for that, in a few weeks.

 

[David W. Fenton]

I added the parentheses around the ACC2000: part, because this KB
article should apply equally well to other versions of Access. You
might try "zeroing out" the contents of the clipboard in the
On_Enter event procedure for both text boxes. I think this would
work, because if there's nothing left to paste then you shouldn't
need to concern yourself with disabling Ctrl V, the edit menu,
etc.

But if they land in the field, and then do the copy, and then return
ot the Access form, that won't work, because no events fire when the
app regains focus after having lost it.

I think you need the to trap for the keystrokes in the KeyPreview
property and the OnMouse events to trap for the mouse events.

 

[Larry Linson]

Larry, watch out: I'll get you for that, in a few weeks.

Yes, Sire. As you say, Sire. It shall be so, Sire. <GRINNIN', DUCKIN', &
RUNNIN'>

{{Note to anyone else: If it wasn't already clear to you, Allen and I are
good friends although we live half-a-world apart and see each other only at
infrequent Microsoft MVP Meetings.}}

 

[Paul Grossman]

These are great suggestions! Thank you for all your help.
The only question I have is suppose someone copies something (important) to
the clipboard and enters the field? I probably wouldn't want to clear other
non-application data from the clipboard in that case.

I agree that trapping every possible combination of paste such as
right-click, menu, ctrl-v and so on is probably not worth the effort. I was
just wondering how some websites can block paste when you try and paste a
password into a confirmation box - I've had that happen to me once. I wish
I saved the website so I can refer to it now but unfortunately I didn't.

----

I'd need to enter and confirm the email address in the _same_ field. So
would I be able to read the contents of the clipboard on the BeforeUpdate
event and perhaps compare the value in the clipboard to the textbox value?
Would that work or are there any other thoughts on that approach?

Thanks again !
Paul.

 

[David W. Fenton]

I was
just wondering how some websites can block paste when you try and
paste a password into a confirmation box - I've had that happen to
me once.

They do it like this:

<input type="text" name="emconfirm"
onpaste="event.returnValue=false;">

In other words, it's supported by the event model of the HTML input
box control.

It's *not* supported by the Access textbox control, so you have to
find a different way.

 

[Paul Grossman]

OK thank you.

So is it the consensus of the newsgroup that this can NOT be accomplished?

I'm very leary of block things like right-clicking, changing menus, or
trapping Ctrl-V becuase I believe that all of these can be subverted in one
way or another - and that is not really a solution.

Also I need to keep in mind that they're using Access 2002 and 2003 - which
uses the Office clipboard -- that can remember up to 25 items cut or copied
to it. So even if I were to somehow read the clipboard and then block
pasting based on what has written there - that doesn't mean they can copy
multiple times and just paste from the Office clipboard (again, I'm assuming
that someone can still get to it even though I disable it from the edit and
view menus).

Am I correct in my thinking here? I would prefer to be wrong and I'd prefer
to find a way to simply prevent a user from pasting in a particular field...
So please, if anyone thinks of something.... let me know because I would
rather do this than not..

Thank you again for all of your time and help

Sincerely,
Paul.

 

[Allen Browne]

OK thank you.

So is it the consensus of the newsgroup that this can NOT be
accomplished?

Paul, did you try out the "alternative" suggestion I posted?

<quote>
Another way might be to declare a form-level variable (in the General
Declarations, at the top of the form's module) to track the number of
characters in the control's Text property. Set it in its Enter event. In the
control's Change event, if the .Text is changing more than a character
at a time (or possibly 2 for some code pages), then the change was
triggered by a paste, so Undo the control.

I haven't followed through on that idea, but there should be a way to get
that to work. It seems safer to me than assuming you've trapped all the
way a paste could occur.
</quote>

 

[Paul Grossman]

Allen, I initially held off because when I read David W. Fenton's post
indicated the user could bypass that by perhaps opening notepad, switching
to it, and then doing a copy from notepad and then go back into access and
paste it there.
According to David, when someone re-activates a form no events will fire
(I'm assuming here that also includes the Enter event). I could however try
the KeyPreview and OnMouse events as David suggests. What do you think?


<David's quote regarding the Enter event>

But if they land in the field, and then do the copy, and then return
ot the Access form, that won't work, because no events fire when the
app regains focus after having lost it.

I think you need the to trap for the keystrokes in the KeyPreview
property and the OnMouse events to trap for the mouse events.

</quote>

So could you let me know what you think about using the KeyPreview adn
OnMouse events instead of using the Enter event?

Thanks again
Paul.

 

[David W. Fenton]

Allen, I initially held off because when I read David W. Fenton's
post indicated the user could bypass that by perhaps opening
notepad, switching to it, and then doing a copy from notepad and
then go back into access and paste it there.
According to David, when someone re-activates a form no events
will fire

That's not what I said. When the Access app gets focus back, no
event is passed to the form and control that had the focus before
the Access window *lost* the focus.

 

[Allen Browne]

Yes, David's point is valid, but not really applicable to what I suggested
(using the Change event to compare Len(.Text) to what it was previously.)

 

[Paul Grossman]

David, I apologize for my confusion and I stand corrected.
I didn't mean to mis-quote you. Thank you very much for clearing everything
up for me. I really appreciate your help.

Sincerely,
Paul.

 

[Paul Grossman]

Allen, I'm going to try it now and I'll post back with my results.

Thanks, Paul.