Having to call SetFocus twice in MS Access 2010 - vba

I found that for a couple of hours this code worked:
If KeyCode = 37 Then
Me.Text12.SetFocus
End If
Then it mysteriously stopped working. I thought it might have had something to do with processing the OnEnter subroutine (I move the cursor to the end of the text field).
However editing out the OnEnter subroutine didn't help.
The only other thing I'd done was change my input/keyboard language (to be able to type quote marks and have them appear immediately, huzzah!)
I now have this code:
On Error Resume Next
If KeyCode = 37 Then
Me.Text12.SetFocus
Me.Text12.SetFocus
End If
Which works. So I know the 50+ pages of search results for SetFocus not working which relate to it being hidden, disabled, not visible, out for tea with the vicar etc do not apply here.
I've also tried setting the focus to another control first, and liberally applied DoEvents as well, neither of which helped.
Has anyone run into anything similar or is this just a really weird Heisenbug?

You must have something else going on. Set a breakpoint on the first Me.Text12.SetFocus and watch what happens when you step through the code (F8).
I suspect that you have another process being triggered that's cancelling the first Me.Text12.SetFocus.
Another possibility is your DB as corrupted. This is something Access is prone to do, especially with lots of edits to the forms and/or reports. Go to File - Info, then click on Compact & Repair Database.
It's not a bad idea to have Access do this automatically whenever you close it. Go to File - Options - Current Database (tab), then check Compact on Close.

Related

MS Access: Repair broken button/control/vba

is there some way to repair broken functionality in ms access, like recompiling the thing?
I have a button on a form that is supposed to run vba code when clicked. The button no longer works, after like a couple of months. Except for the button getting focus nothing happens. I have tried the compact and repair option in access with no luck. The code works fine btw. I have made a new random button somewhere else on the form and literally copy pasted the vba code from the on_click event of the broken button to the new one, and on the new button it works perfectly. No problems at all. The old one, however, nothing. No matter what I do. I deleted the vba code in the on_click event, saved, closed and opened access again, then reentered the code. Still nothing. I tried removing certain functionality from the button by removing line by line, trying to see if any one line is the issue. Nothing again, no errors are being displayed, I don't think the button even runs the vba code at all.
In case someone wants to look at the code:
Private Sub Befehl107_Click()
[NavigationSubform].Form![stoffe_abfrage subform].Form.FilterOn = False
[NavigationSubform].Form![stoffe_abfrage subform].Form.Requery
Me.FilterAlleLink = "Alle"
Me.FocusDummy.SetFocus
End Sub
The button basically turns off the filter on a subform, requeries the form, sets the value for a textbox on the local form, and then gives focus to another textfield. Nothing complex really. I have 3 more buttons of the same type on my form that manage different filters for the same subform with almost identical code, they all work fine. Just this one broke.
Again, the code works fine if I make a new button, but on the old one it does not do anything.
Obviously I can just replace the button, but that would be annoying if down the line there is other functionality referencing it etc. So I was wondering if anybody encountered a similar problem and has a solution. Given that I have only worked with access for like 2 months total and already have this issue I hope there is some way to repair this more quickly, since I am now assuming that this will happen more frequently. Not sure though, maybe someone with more experience knows if this is common.
Edit: I just checked if literally copy pasting the broken button itself works and yes. I copy paste the broken button somewhere else, then copy paste the vba code from the broken button to the copy, and the copy now works...

Write Conflict Error in Access Resolved Once After Saving Class Module

I have a form for viewing data in a table, which can open a pop up form to edit the data.
When data is edited in the pop up form, Access throws a write conflict error upon closing that form and returning to the original.
The strange behavior I'm experiencing is that when I make a change to the popup's class module in VBA, even if I immediately undo the change and save, the error will be resolved exactly once.
To be clear:
I make a change to the popup's class module in VBA (even a change I immediately undo and re-save)
I can open the pop up from my original form, edit records, then close the pop up. No error is thrown on closing the pop up.
I then open the pop up and edit records a second time. Then upon closing the pop up a write conflict error is displayed. This continues each subsequent time.
I now make a change to the popup's class module (again, even a trivial one), the error is resolved for one edit again, and the process repeats.
Does anybody know why this behavior could be occurring? Any help would be much appreciated.
Well the issue centers on if two users, or in this case two bits of code try to edit a record that is already dirty.
If the main form causes the record to become dirty (changed, but not saved), if then you run ANY other code that ALSO changes that data, then you get the conflict.
The simple solution then is to ALWAYS ensure that the the current forms record is safely tucked away and saved before you run + call code that might change that dirty record. And that includes that popup form + class.
So in your code that launches the form/class code? Do this RIGHT BEFORE you launch that 2nd form:
If me.Dirty = True then me.dirty = False
So, the above will safe write out the dirty record, and now you are free to launch/run any other code that might change that record. And because you run the above? Well, the record is not dirty anymore, and thus you should not see nor receive a write conflict error.
So adding a check to save if dirty before you launch/run that additional code/form will resolve this issue. In fact, as a habit, for just about "any" launching of additional UI forms, it a good idea to safe tuck away and save the current forms record when launching additional UI bits and parts.

Stuck in infinite loop. Any way to break vba into Code when Control+Break doesn't work

I have code stuck.
It might be in an infinite loop.
Not sure.
Is there a way to break the program to stop at the current line of code that it is running on?
I'd like to avoid shutting down excel because I want to be able to catch where in the loop it is, and by going into the code, I will be able to tell how much processing was done. I would like to break into the code, if possible.
It is stuck on hour glass.
Ctrl+Break doesn't seem to work
Seems like the running code has hijacked all the quota that cpu is giving to excel.
If there is nothing I can do now, is there something in the future I can do to where I can more easily break into the code?
I'm thinking that an intermittent wait within a loop might be a feasible solution.
In the future, include a DoEvents inside the loop. It will run a little slower, but you will be able to use Ctrl+Break to stop it from running.
Create a progress dialog when entering the loop and include a Cancel button. Within your loop check for the Cancel signal/event. This also gives you some flexibility on how you react to the Cancel - you could stop the loop and display key information in a new dialog box (for example).
Basic steps to achieve what I have described (not necessarily the most elegant or the most re-useable, but simple enough for those of lesser experience):
create a modeless (not modal) Form with either suitable labels or a progressbar item (for
visual effect). Include a public property (Boolean) for Cancel (e.g.
boolCancel)
Place a button on form and onClick set boolCancel = True
In your main code, show the form just before your problem loop.
while in your loop you can update some label or progress bar on the
form so that you have a visual indication of whether the loop is
doing something of value or if it is now simply spinning its wheels.
How you do this depends on what your loop is doing.
Also while in your loop check your boolCancel value. If true then
display any state information you want and break from the loop.
If your loop ends normally, hide/unload the progress dialog.

Background macro/subroutine which is not shown in the Call Stack

I have a workbook with lots of sheets and several macros. When I enter VBA and try to write a new Sub into ThisWorkbook module, I see:
"This will reset your project, proceed anyway?"
assuming, that some project is currently running.
If I press Ctrl + L right after opening the file to check the Call Stack, it just shows nothing.
I did non run any macro myself and there's not a macro, which would handle any event (as far as I checked all sheets and modules in the project) except a little sub for saving event:
Workbook_BeforeSave (ByVal SaveAsUI As Boolean, Cancel As Boolean)
but this one AFAIK should be activated only before saving, thanks to Captain Obvious.
Another mysterious thing with this book is abnormally slow filtering for structured tables, which may be cured by turning off event handler:
Application.EnableEvents = False
Since both these facts are related to Events, I guess they might be somehow connected to each other.
Updated to include comments below.
Well, the problem still exists and I appreciate any idea that may help to locate this pesky macro running totally hidden.
Hm. Anyone with any ideas?
One way to reproduce the behavior that you describe is as follows:
1) Have a public variable which is initialized in Workbook_Open()
2) Have the option Notify Before State Loss enabled (under Tools/Options/General)
In this case when you first open the workbook and try to create a sub you see the warning about resetting the project even though no macro is currently running.
If this is the case, a simple fix (if it still bothers you) is to disable Notify Before State Loss.
On the other hand, it seems that your project has more general problems. VBA projects can become inexplicably corrupt and this might be the case here. A fix which sometimes works is to export all modules, userforms, etc., delete them, and then reimport them. Rob Bovey (a highly respected VBA guru) has written an add-in called Code Cleaner to automate the process. I haven't used it personally but it might be worth a try.

Unable to Debug Code

I have a very weird issue with Access. I have a form for which I created a command button with a simple sub for the Click event:
MsgBox "Hello"
When I put a break point in, it doesn't stop at the break statement, it just executes the sub. I don't program in access everyday but I have been coding on/off with Access for over 10 years. I have never had this issue, and I have worked on this clients Access Database before.
Any advice would be appreciated.
When you check Access Options->Current Database->Use Access Special Keys option, break points will no longer be triggered. Having this option unchecked also prevents things such as F11 opening the access objects window.