Opened form not getting focus

[twgonder]

I've got Form A opening Form B, and then Form A closes.
Form A is started as a Dialog from an autoexec macro.


Sometimes, but not always, the focus goes to the Navigation Pane (pressing tab moves between objects there) or to the VBA Editor, and not to the form that was just opened.
I have to click on the form to get focus back to it.
Anyone know why this might happen?

[CJ_London]

Reason is because of the dialog - it retains the focus until closed so form B doesn’t automatically get the focus when opened. Try swapping the open and close code around

close formA
open formB

[twgonder]

@ CJ_London, thanks for the idea.

Form A is a logon form, that I want to keep dialog, since I don't want anyone poking around until they've completed login.
Form A has a Continue button, which is used after the user has previewed some environmental conditions, then Form B is to open.
That said, I did change the macro to "normal" and Form B did get focus. So that's something. Setting it back to dialog returned to the not getting focus problem.
Form A does close before Form B is opened, and I've even tried setting the focus to a control on Form B as the final step in the Continue button procedure that starts the close of Form A.
But just for fun, I moved the open Form B out of the Form_Close (in Form A) and into the Continue_Click procedure, as the final command and it seemed to work.
I'm guessing this works because Access "thinks" Form A is really now closed, and it will finish the Continue_Click procedure and let Form B really have control now.
Additionally, Form B has a Logout button, which closes Form B and goes back to Form A. That was sometimes acting up too and not giving focus to Form A.
I'll continue testing.

Despite the above, it does seem odd that Access would give focus to the Navigation pane or the VBA editor, no matter where the open for Form B is done, even using dialog.
I can see this being a potential problem in forms that open other forms that can't be opened as the final line of code based upon lots of other code that must run after the open (such as search forms).

[twgonder]

As a final note, even after moving the two open forms to the very end of the procedures that run in Form A and Form B, Access still insists on giving focus (and the cursor) to the VBA Editor, which causes all kinds of problems as I'm already typing the next thing to do and it messes up the code. Oh well.

[moke123]

Access still insists on giving focus (and the cursor) to the VBA Editor,

Only time I believe that's happened for me is when a timer is involved.

[twgonder]

Only time I believe that's happened for me is when a timer is involved.

There are timers involved, but they don't run before the cursor/focus goes astray.

[CJ_London]

Access still insists on giving focus (and the cursor) to the VBA Editor,

There are timers involved, but they don't run before the cursor/focus goes astray.

are you sure about that? And you don't have any stops of breaks in the code so you can step through? VBA window should not be open when testing. For example if you have a break to test screen.activeform/control you will not get a valid answer since it is the vba window that is active.

[twgonder]

are you sure about that? And you don't have any stops of breaks in the code so you can step through? VBA window should not be open when testing. For example if you have a break to test screen.activeform/control you will not get a valid answer since it is the vba window that is active.

I often have the VBA Editor open when testing. I do use breaks, and often, even after doing Ctrl+Shift+F9, breaks will happen, stopping on a line without the red dot (and no error).
Form B is opened from Form A, so Form A was the active form, where I pressed the "Continue" button to force Form B. So, the VBA editor wasn't the active window. The cursor usually goes to the very beginning of the displayed module, the first line being a comment. Clicking on Form B in the detail area will make the form active, the cursor in the correct text box and functions normally with entry (and everything else).

Is there some other reason that the VBA editor window shouldn't normally be open during development and testing?

[CJ_London]

It can be open during development and will open during testing for any breaks you may have or unhandled errors. It it opens to a line of code without a break or error it implies a’ghost’ break - one that is not visible but the vba editor thinks there is one. This usually occurs when you have set a break point and then removed it whilst the code is running. I.e. you have set a breakpoint, code runs and pauses at that point. You remove the break and click F5 to continue running the code, maybe you have changed the code, maybe not. If you have, depends on the changes you have made, but you risk corruption - sometimes when you make a change the editor will tell you the code has been stopped. Better to stop processing, make your changes and run the routine again.

to get rid of the ghost breaks you can try using the remove all break points button but usually the best thing to do is compact/repair and/or decompile