What can prevent an MS Access 2000 form from closing? - ms-access

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?

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

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.

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

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.

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.

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

Related

Unable to replicate Refresh All quick access toolbar button in form

I have a form with several subforms whose content is edited in separate forms, opened by command buttons.
When the data in those forms is updated, and the extra forms closed, naturally the main form needs to be refreshed before those changes can be seen. Clicking the Refresh All quick access toolbar button achieves this perfectly.
So I made a macro for the "got focus" event on the main form to refresh it, but it does nothing. I tried repaint and requery as well, applying the latter specifically to the subforms in question, and ran them out of vba instead of an access interface built macro too, none of these seem to solve the problem.
vba coding:
Private Sub Form_GotFocus()
Screen.ActiveForm.Requery
Screen.ActiveForm.Repaint
Screen.ActiveForm.Refresh
Me.sfmContact.Requery
Me.frmCustCert.Requery
Me.frmCustReq.Requery
End Sub
Annoying thing is that if I put this (or even just the macro or Screen.ActiveForm.Refresh) in the on click event of one of the controls it works fine. Just can't seem to make it work in any automatic events that don't require thought or clicks from the end user.
This question is sort of a dupe of Refresh button on an Access form but that question is over a year old, and has no accepted answer. So I've expanded on it.
What you mentioned in your comment there is correct:
My guess is that it's not running it, but I don't know why. I got mixed up between OnActivate and OnLoad, which is why I didn't try that option. That works and solves the problem, but why wouldn't GotFocus fire? Surely the main form lost focus when another form got it for updating, and then it got it back again when the other form closed/anything in the main form was selected...
To avoid this type of error in the future, it may be prudent to specifically name the form in your code instead of using the "Me." command, as that only works for current focus. For instance:
Me.sfmContact.Requery > Forms![FormName].sfmContact.Requery
Alternatively, you could just set the focus to the form in question before that sort of coding.
Forms![FormName].SetFocus

Changes to forms in Access occassionally become permanant

I have a home form that automatically opens up to provide the user of my Access database navigation and a few other services, however, a lot of what the home form does, is heavily reliant on VBA, so unless the user has accepted the security warning, things will break.
To work around this, I have hidden everything on the form except for a label telling the user that they need to enable Macros in the Security Panel. Once the user does this, the form is obviously re-loaded, and VBA code will run on_load, showing all the buttons, and hiding the label.
However, occasionally I will open up the database, and all the buttons will be visible, and the warning label hidden, before I check the security warning. If I open them up in design view, the visibility property of each object is opposite of what I originally set it as, and I have to go reset it. I haven't been able to reproduce this error on command, but it happens reasonably regularly, without any kind of pattern that I have noticed. There are a few other forms which also have changes in their layout, and it occasionally happens to them as well.
I'm wondering if this is a problem anyone else has faced, and if so, what may have caused it.
This can be caused by:
Opening the database
Enabling macros
Switching your home form to Layout View
Making any kind of design change
Closing the form and saving changes
The change of visibility from your VBA is locked in when you save changes from Layout View.
Could this be what is happening?

Error upon opening form

I am going crazy with the easiest piece of code that just won't work. I can't fugure out why. I have a button on a form that opens another form but when i click it I get the following error and don't really know what to change:
my code click code is:
Private Sub HSbrowse_Click()
DoCmd.OpenForm "frmSearchPCR"
End Sub
Any Ideas?
I've had this issue several times. I believe that it is caused by the module of your form becoming corrupt. To fix it, set the "Has Module" property of your form to "No" and save and close your form. This will delete the module and any code it contains, so you will need to copy your code first. Open the VBA window to verify that the module was deleted, then reopen your form and set its "Has Module" property back to "Yes" and paste your code back in. This method has solved this problem for me on more than one occasion.
Does the current form has any ActiveX Control in it?
If not then your form may be corrupt,
rebuild your database using e.g. TM-RebuildDatabase
Start by removing individual controls one-at-a-time. When your error goes away you will know the offending control, if that is indeed the problem.
Does the form have underlying data? Did you remove that to see if the problem changes?

Run VBA code whenever a tabbed form is reselected in Access

EDIT: For clarification, I'm talking in the below post about tabbed document browsing, not a Tab Control. However, if you're looking for roughly the same problem but regarding a Tab Control, Gord Thompson's answer is correct. Two answers for the price of one!
I've got an Access 2007 database that uses tabbed documents. I need to run some VBA code every time a user selects the form called "Reports", either via opening it or clicking on its tab if it's already open.
I could achieve much the same thing by closing it each time it's used and running the code on an OnLoad event, but ideally I'd like to keep it open so that users can keep the settings of the various drop down boxes, radio boxes etc that they've already set on "Reports".
I was hoping for an event that could run code on tab reselection, but neither of my guesses (OnCurrent and GotFocus) seem to work (OnCurrent works only when the form is opened, like OnLoad would).
Any ideas greatly appreciated - can't find what I'm looking for on Google, though I suspect that's because I don't know exactly what I'm looking for.
The .Value property of a TabControl returns the index (zero-based) of the current page. So, if I have a TabControl named TabCtl14 that contains two pages, FirstPage and SecondPage, then the code...
Private Sub TabCtl14_Click()
If Me.TabCtl14.Value = 1 Then
MsgBox "SecondPage was clicked."
End If
End Sub
...displays the MsgBox whenever I click the "SecondPage" tab in the TabControl.
Have found the answer I was looking for. It's the OnActivate event.

MS Access Tab Control: Wrong focus

I have a tab control with different pages. When starting up the form with this tab control the tabs get lost and the inner page gets all the screen focus. The tab control is used for navigation so the user will get lost this way.
Is there any way to let the tabs be visible on the screen without just resizing the screen to be smaller?
Desired result:
+--------------------+
| Tab1 | Tab2 | Tab3 |
+--------------------+
| Name: ______ |
Actual screen:
^
+--------------------+ |_|
| Name: ______ | | |
Reducing the size of the tab control works (as you discovered yourself), however there is an alternative workaround:
Add a command button and align it with the top left corner of the tab control
Set its Tab Stop property to No (in the 'Other' tab of the command button property sheet)
Send To Back to put the command button behind the tab control
In the Form's OnOpen or OnLoad event, call the .SetFocus method on the command button
Use SendKeys (I know, I know...) to tab to the Tab Control
Sample code:
Private Sub Form_Open(Cancel As Integer)
Me.HiddenCommandButton.SetFocus
SendKeys "{Tab}"
End Sub
Explanation of the above steps:
This allows you to dictate to Access where it should line up the form on screen.
Setting the Tab Stop to No for the command button prevents users from accidentally tabbing to it and causing confusion.
Sending the button to the back hides it from the user and prevents it from interfering with any mouse clicking.
Setting focus to the command button at form start up is necessary since we turned off the Tab Stop property in step 2.
Using SendKeys (always a last resort, and for good reason) to simulate a tab press provides "keyboard focus" to the Tab Control (as long as the tab control is the first control in the tab order for whatever section of the form the control is a part of).
Miscellaneous Notes: At the asker's request I am including a couple of comments as part of the answer itself:
#mwolfe: One final note on SendKeys...it blows up under UAC in
Vista/Win7. If you can live without
the keyboard focus, I'd say leave
SendKeys out entirely. If you need it
you'll either want to add error
handling to ignore the error (if you
don't mind some of your users losing
keyboard focus functionality) or
bypass SendKeys and use the WinAPI
directly. Karl Peterson offers a
turnkey solution here:
vb.mvps.org/samples/SendInput I have
never used it so can't comment on its
reliability, but Karl is a Microsoft
MVP so he's get some credibility.
#Roman Glass: mwolfe02 I trust you in that this method will work, but the
focus is crucial for me AND some users
are working under Windows 7. I will
drop this issue for the moment to find
out about the user reactions.
Nevertheless I think your solution
deserves a solved. In the end I have
to talk with the WinAPI. Maybe you can
edit your answer to include this
comment directly. Thanks!
For those who may find this answer in the future, please take note that Step 5 above is only necessary if you need the tab control to receive keyboard focus (a critical requirement for the original asker). If you can live without it, I would suggest that you do.
UPDATE: As David Fenton points out in the comments, you can use Ctl + Tab/Ctl + Shift + Tab to move back and forth between the tabs. This is consistent with most tabbed interfaces (eg, browsers) and eliminates the need to use SendKeys.
Hmmm, I know I've only played with the Tab control once or twice - but never had a problem with it showing up on the form when the form is executed/loaded. Granted, I've never had it in any place except the Detail section of the form, but I'd say check to see if the beast has somehow gotten it's Enabled or Visible property (if applicable) set to No. Of course, I could be wrong - it happens, and I am eager to learn something new when it happens. :)
I don't know that I understand the question, but in a comment, you say that Access doesn't allow you to set focus to a tab control, but you can set focus to the tab page:
Me!ctlTab.Pages(N).SetFocus
...where N is the index of the tab page you want to set focus to), or with:
Me!pgeTabPageName.SetFocus
Both of these work to set focus to the tab page.
You say you want to set focus to the tab control, but I can't figure out why you'd want to do that. The tab control itself has no elements that can get focus -- only the members of its Pages collection do.
Again, I would suggest that you've painted yourself into a corner for some other reason and there's no solution. Therefore, you have to figure out how to avoid getting into that insoluble problem. I simply don't understand your explanation of the problem well enough to be able to offer a solution, but I doubt there's no way to resolve the issue through a different approach.