An obscure (low-severity) bug involving AutoKeys, MouseMove and RunCommand
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.The return of the performance leak - this time with subreports
Anyone remember the v2405 bug that caused loading and closing forms to become slower over time? We found something similar in the current release (tested with semi-annual 2508 (19127.20484)), just with sub reports instead of forms. Here are the repro instructions: Repro instructions Table 1. Create a "numbers" table with a PK field "nr" (Long Integer). 2. Fill it with the numbers from 1 to 100: Dim i For i = 1 To 100 CurrentDb.Execute "INSERT INTO numbers (nr) VALUES (" & i & ")" Next i Sub report 3. Create a new empty report in design view, using the "numbers" table as the record source. 4. In the detail section, add two text boxes "Text1" and "Text2" next to each other, both with the "nr" field as their control source. 5. Reduce the size of the detail section to one "row", containing just the two text boxes. Remove the page header/footer. 6. Add an Format event handler to the detail section with the following content: Me.Text2.Visible = False 7. Save the report as "sub". Main report 8. Create another report "main", which contains nothing but the "sub" report as a subreport in its detail section. Set the record source of "main" to "SELECT * FROM numbers WHERE nr <= 10" Reproduce problem 9. Create the following method in a module: Sub report_loop() Dim i As Long Dim start_time As Single Dim report_name As String Dim path As String report_name = "main" For i = 1 To 40 path = Environ("Temp") & "\testreport.pdf" start_time = Timer DoCmd.OpenReport report_name, acViewPreview DoCmd.OutputTo acOutputReport, report_name, acFormatPDF, path DoCmd.Close acReport, report_name Debug.Print Timer - start_time Next End Sub 10. Run report_loop. Observe that each report export gets slower and slower. Analysis Compare the first and last number in the immediate window: on my machine it's 0.4s for the first report and 2.3s for the last. Note that if you run report_loop again, it will start slow! In other words, each report export causes MS Access to "leak performance" that is only regained after restarting Access. We were able to reproduce this issue with Microsoft 365 semi-annual channel, Version 2508 (19127.20484). I'll do more tests tomorrow and try different older versions to find out when this bug was introduced. Workarounds If you move the visibility code from the Format event to the Print event, the problem still occurs, but slower (0.4s -> 0.72s instead of 0.4s -> 2.3s). The workaround that worked for us was to use =IIf(...) in the control source instead of modifying the visibility. Obviously, that only works for text boxes, not for lines or other controls.