First Published 2 Apr 2023             Last Updated 14 June 2023


1. The popup breakpoint issue

This article describes a long term Access issue which was brought to my attention in a thread at AccessForums.net:
      DoCmd.GoToRec , , acNewRec throws run-time error 2046

Using a popup form, stepping through code to examine it can cause code to error in specific situations,

I’ve seen similar behaviour over the years where adding a breakpoint prevents code running.
However, I’ve never really studied the causes until now.

After testing, this particular issue has existed in all Access versions since 2002

To replicate, add code to a POPUP form to navigate between records. For example:


NOTE: Only the DoCmd.GoToRecord code is needed for navigation.
The MsgBox and OpenForm code lines have been added to demonstrate the issue

On any of the navigation button events, add a breakpoint to step through the code – in this case on the MsgBox line


From Access 2002 onwards, the code errors on the GoToRecord line. The error number depends on the Access version

A365: error 2499 - You can't use the GoToRecord or SearchForRecord action or method on an object in Design view.
A2003/2007/2010: error 2046 - The command or action GoToRecord isn't available now
A2002: error 2499 - same as for A365
A2000: No error!

The breakpoint causes the popup form to behave as though it is in 'design view'
NOTE: the error depends on the Access version NOT the file format

WORKAROUND:
Luckily, once you are aware of the cause, there is a very simple workaround:
Enable the line DoCmd.OpenForm Me.Name, acNormal

No error occurs as the form is set to form (normal) view before running DoCmd.GoToRecord

Alternatively,
a)   Set Popup = No. No error. No need to specify Form view
b)   Use Access 2000 (a bit extreme as a solution, methinks!)



UPDATE 14 June 2023:
After discussion with a member of the Access team, I now have an almost complete understanding of why this happens. The following account is based on this discussion.

Access keeps a notion of the 'current context' while running code. Actions like DoCmd.GotoRecord that don’t specify an object will act on the 'current context'.
When popup forms run a message box or hit a breakpoint in VBA code, the form loses focus.
The 'current context' is set to the current document in the Access window.

If no other form is open, the only thing open in the main Access window is the navigation pane, so that becomes the context.
Since DoCmd.GotoRecord doesn’t make sense for the navigation pane, an error occurs.

However, if another standard form is also open in the main Access window, that form gains the focus when the popup form loses it!
The result is that DoCmd.GotoRecord does not give an error, but would navigate to the specified record in THAT form.
In my opinion, that behaviour is even worse - very undesirable!

For info, trying to specify the code context object using code like this on the popup form makes no difference:


Exactly the same behaviour / errors occur as was originally the case. The code context object doesn't apply to popup forms

Calling DoCmd.OpenForm on the popup form avoids this issue is that it puts focus back on the popup form, making it the current context again, so the DoCmd.GotoRecord works as intended.

I seems unlikely that Microsoft will change this behaviour so that the popup form retains the current context, as doing so could cause additional issues such as breaking other code. In any case there is a clear 'workaround'

However, better documentation and error message would help clarify the behaviour observed.

NOTE: Above, I said I had an (almost) complete understanding. The only thing I still don't understand is why it works without error in Access 2000



Click to download: Example databases to reproduce the issue
      Popup Break GoToRecord Error DEMOS     (zip file with ACCDB & A2000 MDB files)




2. Additional Info about Popup forms

Popup forms are independent of the Access application window. This has several advantages such as:

a)   users can move popup forms to another monitor if required

b)   popup forms can be displayed 'floating on the desktop' with the Access application window hidden.
      For more details, see my article: Control the Application Interface


However, this property also has some (possibly) unwanted side effects such as:

a)   If a popup form is dragged to a secondary monitor and then saved, it will retain that position in future.
      This will be an issue for users with only one monitor as it means the form will be hidden 'off-screen'

b)   The commands Screen.ActiveForm and Screen.ActiveControl do not work for popup forms.
      There is no equivalent code Screen.ActivePopupForm and Screen.ActivePopupControl
      In each case, the code will return details for the 'topmost' standard form that is currently open.
      If no other form is open, error 2475 occurs.


c)   If a popup form is maximized, the Access menu bar, ribbon and navigation pane are all inaccessible





Feedback

Please use the contact form below to let me know whether you found this article interesting/useful or if you have any questions/comments.

Please also consider making a donation towards the costs of maintaining this website. Thank you



Colin Riddington           Mendip Data Systems                 Last Updated 14 June 2023

Return to Access Blog Page

Return to Top