What can prevent an MS Access 2000 form from closing?

My Access 2000 DB causes me problems - sometimes (haven't pinpointed the cause) the "book" form won't close. Clicking its close button does nothing, File -> Close does nothing, even closing Access results in no action. I don't have an OnClose handler for this form. The only workaround I can find involves opening the Vba editor, making a change to the code for that form (even adding a space and then immediately deleting the space), and then going back to close the "book" form, closing it, and saying "no, I don't want to save the changes". Only then will it close. Any help?

From stackoverflow Thelema

• That sure is weird. Do you have any timer controls on the form? If you do, try disabling it in the OnClose.

  Thelema : No, I don't use any timer controls anywhere in the whole project.
  From Echo

• There is a possibility that the message box that asks if you want to save changes is being displayed behind the form. I believe that this message box is modal so you must click yes or no before you can do anything with the form which is why you can't close it.

  Thelema : I don't believe this to be the case, as after trying to close the form, I can still interact with the form, go to next record, make changes, etc.
  From Bryan Roth

• Does your form have an unload event? That can be canceled, and if it is, the form won't close when it's in form view. It will only close in design view, which, when you edit the vba code is what the form does in the Access window when you're editing the code.

  Thelema : The form has only OnCurrent, BeforeUpdate and OnOpen events.
  From Chris OC

• Here's a forum post describing, I think, the same problem you face. Excerpt belows states a workaround.

  What I do is to put code on the close button that reassigns the sourceobject of any subforms to a blank form, such as:

  me!subParts.sourceobject = "subBlank" 'subBlank is my form that is totally blank, free of code and controls, etc. docmd.close acForm, "fParts", acSaveNo

  The above 2 lines is the only way I've found to prevent the Access prompt from popping up.

  http://bytes.com/forum/thread681889.html

  From micahwittman

• Does your form have a checkbox, toggle button or option button? There's a bug in Access 2000 where Access won't close if you test the value without explicitly using the Value property in the vba code, like this:

  If Me.chkbox Then
  

  versus:

  If Me.chkbox.Value Then
  

  Thelema : I do have a checkbox on all my forms, with the exact same code. I don't think this causes my original problem, but I'll fix this everywhere so I don't run into this bug.

  Chris OC : Now you know why the form wouldn't close.

  Thelema : The form closing bug seemed fixed before I made this change.

  Chris OC : It seems fixed cuz you're using a workaround. Do you understand why the workaround works? It's because it's making a design change, putting it in design mode which allows the form to close. Remove workaround & use Me.chkbox.Value syntax on forms using filter-by-form - that's one trigger of this bug.
  From Chris OC

• Another alternative is

  (Me.Checkbox)
  

  or my preferred syntax:

  (Me!Checkbox)
  

  It seems to me that there is much confusion in the posts in this topic. The answer that was chosen by the original poster cites an article where the user had a prompt to save design changes to the form, but the problem described here seems like it's a failure of the form to close, not a save issue (the save issue came up only in the workaround describing going to the VBE and making a code change).

  I wonder if the original user might have incorrect VBE options set? If you open the VBE and go to TOOLS | OPTIONS, on the GENERAL tab, you'll see several choices about error handling. BREAK ON UNHANDLED ERRORS or BREAK IN CLASS MODULE should be chosen, but it's important to recognize that if you use the former, you may not see certain kinds of errors.

  There's not really enough detail to diagnose much more, other than the fact that the reference to the checkbox control seemed to have been causing the problem, but there are a number of Access coding best practices that can help you avoid some of these oddities. The code-related recommendations in Tony Toews's Best Practices page are a good place to start.

  --
  David W. Fenton
  David Fenton Associates

  From David-W-Fenton