Setup

1. Create a new database.

2. Create a new module with the following content:

Function myPaste()
DoCmd.RunCommand acCmdPaste
End Function

and save it as “Module1”.

3. Create a new macro with the following content:

Submacro: ^b
RunCode =myPaste()

and save it as “AutoKeys”.

4. Create a new Form with

– a text box “Text0” and
– a button “myButton”

and save it as “Form1”.

5. Add two event handlers ([Event Procedure]) to myButton with the following code:

Private Sub myButton_Click()
Text0.SetFocus
DoCmd.OpenForm “Form2”
End Sub

Private Sub myButton_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
‘ Deliberately empty
End Sub

6. Create a new Form with

– a text box “Text0”

and save it as “Form2”.

Repro

Copy text into the clipboard (for example, the word “test”).Open Form1.Click on the button. Don’t do anything after clicking the button. In particular, do not move the mouse for a few seconds (so that it still hovers over the space where the button was while the new form opens).Hit Ctrl-b

Expected result

Text0 in Form2 now contains the content of the clipboard.

Actual result

Text0 in Form1 now contains the content of the clipboard.

Notes

This bug is more of a curiosity than a real problem. It can be reproduced with the current channel of Microsoft 365 (v2409, 18025.20160) and with various older versions of 365, but not with Access 2007, so it was probably introduced at some time during the last 17 years. There are more important bugs to fix in Access, so it’s probably not worth investing more time in it, but I still felt the need to document this issue.On workaround to prevent the bug from happening is to add an (empty) KeyDown handler to either Text0 in Form2 or, after enabling Key Preview, to Form2 itself.The MouseMove event handler on the button is required to reproduce the bug.We discovered this issue because our applications use a “Ctrl-v” AutoKey that sanitizes the clipboard (replace tabs with spaces, remove unprintable characters, replace line breaks with spaces if the target is a single-line textbox) before executing the paste operation.One might assume that Text0.SetFocus is part of the problem, but it isn’t. It just helps to demonstrate the issue. If you remove it, Access will try to paste the text on the button in Form1 instead of the text box in Form2.

​ Setup 1. Create a new database. 2. Create a new module with the following content: Function myPaste()
DoCmd.RunCommand acCmdPaste
End Function and save it as “Module1”. 3. Create a new macro with the following content: Submacro: ^b
RunCode =myPaste() and save it as “AutoKeys”. 4. Create a new Form with- a text box “Text0” and- a button “myButton”and save it as “Form1”. 5. Add two event handlers ([Event Procedure]) to myButton with the following code: Private Sub myButton_Click()
Text0.SetFocus
DoCmd.OpenForm “Form2”
End Sub

Private Sub myButton_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
‘ Deliberately empty
End Sub  6. Create a new Form with- a text box “Text0″and save it as “Form2”. Repro Copy text into the clipboard (for example, the word “test”).Open Form1.Click on the button. Don’t do anything after clicking the button. In particular, do not move the mouse for a few seconds (so that it still hovers over the space where the button was while the new form opens).Hit Ctrl-b Expected result Text0 in Form2 now contains the content of the clipboard. Actual result Text0 in Form1 now contains the content of the clipboard. Notes This bug is more of a curiosity than a real problem. It can be reproduced with the current channel of Microsoft 365 (v2409, 18025.20160) and with various older versions of 365, but not with Access 2007, so it was probably introduced at some time during the last 17 years. There are more important bugs to fix in Access, so it’s probably not worth investing more time in it, but I still felt the need to document this issue.On workaround to prevent the bug from happening is to add an (empty) KeyDown handler to either Text0 in Form2 or, after enabling Key Preview, to Form2 itself.The MouseMove event handler on the button is required to reproduce the bug.We discovered this issue because our applications use a “Ctrl-v” AutoKey that sanitizes the clipboard (replace tabs with spaces, remove unprintable characters, replace line breaks with spaces if the target is a single-line textbox) before executing the paste operation.One might assume that Text0.SetFocus is part of the problem, but it isn’t. It just helps to demonstrate the issue. If you remove it, Access will try to paste the text on the button in Form1 instead of the text box in Form2.  Read More

​