Proper focusing of windows in MS Access (natively or by a code) (4 Viewers)

mldntodorovic

New member
Local time
Tomorrow, 00:02
Joined
Jan 17, 2025
Messages
6
Hi everyone,

My name is Mladen, and I'm a bit new to all of this, but I have scavenged the forums and the rest of the internet for a few months by now, and never found a solution to this problem, or something similar as a solution, and I still refuse to believe that this exists as a problem in this day and age.

Is it possible to make MS Access to properly focus popup windows?

Let me explain: I have a navigation form that is not a popup window, and it stays in background, and so is ribbon, status bar, navigation pane (which will later be hidden for user), and so on... When I open another form (I have like 200+ forms and similar number of reports, but let's disregard the reports now) that is a popup (every one except navigation form is a popup), and then open some other form from the ribbon or from another form via button command, and then close that form to go back to the previous one or to do something else, it always switches focus to something else (everything else) but the opened forms. Why is that? I had to implement a code that will type SHIFT+F6 several times depending on what is also shown on the screen (if there is navigation pane, status bar...). So it depends how many times you have to press this combination to get back focus the form, and not the ribbon or status bar or navigation pane or whatever it decides to focus on.
Also, Form Activate, Form Got Focus, Lost Focus... all of that never works because all those forms think that they always have focus. How is that even possible? Can it be changed, so I can have a normal behavior and use some of those events.

Also, user demands to have a button on the ribbon to close the currently focused (selected) form or report, and it won't work if my code on every form's close event doesn't type SHIFT+F6 (number of times depends on cases that I described above) to activate the last focused form so it can be selected and that ribbon code can close it.

Yeah, I know about the modal option and it works how it should work (it focuses the form that opened the modal form), and then I do not use the "SHIF+F6" code on OnClose event on my forms (if the form is modal), because it then shifts focus to something else.
I can't use modal on every form because user needs to open multiple windows to work in the app. I can use it sometimes when I need from user to close that form, so I won't allow the user to interact with somethin else before he's done with the modal form.

I thought maybe there is a setting in MS Access (I have 2021), that will do this natively. I saw that in older versions of MDE and MDB files and it works perfectly (all events trigger correctly, and user can use ribbon or menu bar to close the currently active window). I think it's 2007 and 2010 office, I'm not sure.

Don't get me wrong, my solution works (somewhat, if we exclude the lack of triggering the events like Form_GotFocus, Form_LostFocus, Form_Activate), but I still refuse to believe that this can't be done natively in this day and age, as I've said above.

Any idea?
 
Welcome to Access World! We're so happy to have you join us as a member of our community. As the most active Microsoft Access discussion forum on the internet, with posts dating back more than 20 years, we have a wealth of knowledge and experience to share with you.

We're a friendly and helpful community, so don't hesitate to ask any questions you have or share your own experiences with Access. We're here to support you and help you get the most out of this powerful database program.

To get started, we recommend reading the post linked below. It contains important information for all new users of the forum:

https://www.access-programmers.co.uk/forums/threads/new-member-read-me-first.223250/

We hope you have a great time participating in the discussion and learning from other Access enthusiasts. We look forward to having you around!
 
Since that was your first post to the site, let me say "Welcome to the forums."

Since this is a problem with forms, I am going to move your question to the Forms topic.

After that, here is my question:

It appears that you can have multiple forms open at once and want Access to return focus to the previously opened form, the one from which you opened the form that you are now leaving. But what happens instead is that focus goes elsewhere, to one of the other open forms. Is that a correct assessment?
 
Welcome. I find that allowing multiple open forms that the user switches between is too confusing for most users so I almost never allow it. I also don't make the "first" form opened from a menu/ribbon/switchboard a dialog. I use the Overlapping Windows style rather than the Tabbed Documents style and I do not maximize the forms or reports as they open. All this works together. The forms are sized to be as big as they need to be to show the data they contain. Then if a "first level" form needs to open a second form, I hide the "first level" form and open the second tier form as a dialog. The user must complete his action on that form and close it which then reopens the calling form. Sometimes, the user needs to see both the "first level" form and the popup. I do allow that but because the popup is modal, the user can move the popup form around but he can't click back into the "first level" form until he closes the popup. Same technique, if the "second level form needs to open a "third level form". Hide the second level and when the third level closes, the second level reopens where it was. When the second level closes, the first level reopens where it was.

This is a very simple sample that shows how this linking works using the OpenArgs parameter in case that helps. The "called" form always knows what form opened it because the name is passed via the OpenArgs so when any form closes, it opens the form from the OpenArgs OR if that is empty, it opens the switchboard. If you need to use OpenArgs for other things, you can simulate an array by using the semi-colon as a separator. Just make sure to always have the first argument be the calling form.

Otherwise, you might want to look at the "big" Northwinds template since it allows (in some cases) multiple instances of the same form to be open.
 
Welcome. I find that allowing multiple open forms that the user switches between is too confusing for most users so I almost never allow it. I also don't make the "first" form opened from a menu/ribbon/switchboard a dialog. I use the Overlapping Windows style rather than the Tabbed Documents style and I do not maximize the forms or reports as they open. All this works together. The forms are sized to be as big as they need to be to show the data they contain. Then if a "first level" form needs to open a second form, I hide the "first level" form and open the second tier form as a dialog. The user must complete his action on that form and close it which then reopens the calling form. Sometimes, the user needs to see both the "first level" form and the popup. I do allow that but because the popup is modal, the user can move the popup form around but he can't click back into the "first level" form until he closes the popup. Same technique, if the "second level form needs to open a "third level form". Hide the second level and when the third level closes, the second level reopens where it was. When the second level closes, the first level reopens where it was.

This is a very simple sample that shows how this linking works using the OpenArgs parameter in case that helps. The "called" form always knows what form opened it because the name is passed via the OpenArgs so when any form closes, it opens the form from the OpenArgs OR if that is empty, it opens the switchboard. If you need to use OpenArgs for other things, you can simulate an array by using the semi-colon as a separator. Just make sure to always have the first argument be the calling form.

Otherwise, you might want to look at the "big" Northwinds template since it allows (in some cases) multiple instances of the same form to be open.
NW Developer does support multiples instances of Orders and Purchase Orders, on the assumption that a user might want to compare two or more POs or Orders while discussing them with clients. However, we used Tabbed Documents in NW developer, not Overlapping Windows, so the challenges differ.
 
The tabbed document interface does not show multiple tabs at once which is why I never use it. So, I'm pretty sure that Northwinds has to open the multiple forms as popups but not in dialog mode or you couldn't use them both.
 
This is how it is done. One order per tabbed window.

1737150706497.png
 
Thanks George. I thought you could see both orders at the same time. Without being able to see the orders side-by-side, I never would have implemented this "feature", that's why I thought you did it with popups. Not being able to see more than one object at a time is the ONLY reason I never use the tab dialog view. But then we've had this discussion before;)
 
Thanks George. I thought you could see both orders at the same time. Without being able to see the orders side-by-side, I never would have implemented this "feature", that's why I thought you did it with popups. Not being able to see more than one object at a time is the ONLY reason I never use the tab dialog view. But then we've had this discussion before;)
The templates are showcases of what is possible with Access, in addition to illustrating what we consider good practices. Tabbed Windows are a significant feature of modern Windows applications. We needed to illustrate that.

When starting a new database, I always use Overlapping Windows mostly for the same reasons you do, I believe.
 
When I open another form (I have like 200+ forms and similar number of reports, but let's disregard the reports now) that is a popup (every one except navigation form is a popup), and then open some other form from the ribbon or from another form via button command, and then close that form to go back to the previous one or to do something else, it always switches focus to something else (everything else) but the opened forms. Why is that?

The nature of popup forms is they are independent of the application interface.
As a result, the form is never considered active by Access and you can't reference it in the way you want.

Try this. Open a standard form, go to the Immediate window and type ?Screen.ActiveForm.Name then press enter.
It will return the name of the form
1737192398582.png


Repeat with just a popup form open. You will get an error message as there isn't an active form 'on the screen'
1737192577703.png


If you have both a standard & a popup form open with the focus on the popup, Access will again return the name of the standard form.
As you have seen, setting the forms as modal doesn't help in this respect.
The same applies to popup reports
.
This also explains why you can't get certain events to fire on popups

I had a similar conversation with a member of the Access team a couple of years ago suggesting the need for an ActivePopupForm/ActivePopupReport property. He agreed in principle and IIRC posted it as a suggestion on the Feedback Portal though I can't find it now. Suggest you post the same request on the Feedback Portal and if its popular enough, it may get implemented.

For info, I use popup forms whenever I hide the Access application interface.
It works well but you need to be very careful to always reference forms by name for the reasons stated above.

 
Last edited:
you may also try to pass the name of the Calling Form (as OpenArgs) when you open a form, ie:

Code:
Private Sub Command0_Click()
DoCmd.OpenForm FormName:="Form2", WindowMode:=acDialog, OpenArgs:="Form1"
End Sub

Form1 is the form where command0 button resides.
then save the openargs so that later when you close the form
you can Setfocus to the Calling form.

see this demo and open form1.
 

Attachments

When starting a new database, I always use Overlapping Windows mostly for the same reasons you do, I believe.
I was soooooo disappointed in the tab view. I think it went along with what the Access team designers thought they would do with the Nav Pain (sic). But both were poorly thought out and so never panned out as a viable interface for the user. Tab view for the developer is ridiculous. I can't believe any professional developer actually uses it. I would have considered using tab view for the user but since you have to shut Access down to switch views it is too much of a PITA and so I never built a tab interface for a client. I do frequently use tabs on forms and they are very convenient and allow the form to be very well organized and show a lot of data without being crowded. So, it isn't the concept of tabs that is poor, it is how the tabbed view actually works that is poor, at least for development work.

@isladogs explanation for why popup forms cause problems was very good. I discovered some of the issues years ago but never got into the nitty-gritty to figure out why they didn't catch focus the way I thought they should. I just moved on and created a method I still use that avoids the issues.
 
This also explains why you can't get certain events to fire on popups
This line caught my attention, so I tried to reproduce that through this
Repeat with just a popup form open. You will get an error message as there isn't an active form 'on the screen'
I did encounter an error when attempting to retrieve the active form name from the Immediate window while only the popup was open. However, when I added a button within the popup to query the active form, it correctly returned the popup as the active form.

This made me curious to see what would happen if both the standard form and the popup were open. To test this, I added a timer to both forms that fired every second to query the active form. Both forms correctly returned the active form, except that when switching to the VBA IDE, the standard form was set as the active form.

You got examples of events not firing from the popup?
 
Since that was your first post to the site, let me say "Welcome to the forums."

Since this is a problem with forms, I am going to move your question to the Forms topic.

After that, here is my question:

It appears that you can have multiple forms open at once and want Access to return focus to the previously opened form, the one from which you opened the form that you are now leaving. But what happens instead is that focus goes elsewhere, to one of the other open forms. Is that a correct assessment?
It not just goes elsewhere, it NEVER goes to another form, except the navigation one (the one that is not a popup). It always goes to the ribbon, or maybe status bar (depending of what is shown currently to the user). Let's say I have ribbon, status bar, navigation pane, and this navigation form that is not a popup, if you open another form (via ribbon or via another form, it doesn't matter) and then close that form, focus never goes to the previous form that had focus. You have to type SHIFT+F6 to get focus back to the popup that had the focus. You can open tens of forms, and if you programmatically add on their on close events to type SHIFT+F6, it will always do the proper focus to the previously focused popup. If you disable navigation pane, or something else (for end user not to see), you have to adjust just how many times this sub presses SHIFT+F6, to get proper focus every time next time. It works, don't get me wrong, but I just can't believe that this is native behavior?!
 
How are you opening your forms? Do you have code trying to set focus on something? If yes, how? if no, why not?
 
Welcome. I find that allowing multiple open forms that the user switches between is too confusing for most users so I almost never allow it. I also don't make the "first" form opened from a menu/ribbon/switchboard a dialog. I use the Overlapping Windows style rather than the Tabbed Documents style and I do not maximize the forms or reports as they open. All this works together. The forms are sized to be as big as they need to be to show the data they contain. Then if a "first level" form needs to open a second form, I hide the "first level" form and open the second tier form as a dialog. The user must complete his action on that form and close it which then reopens the calling form. Sometimes, the user needs to see both the "first level" form and the popup. I do allow that but because the popup is modal, the user can move the popup form around but he can't click back into the "first level" form until he closes the popup. Same technique, if the "second level form needs to open a "third level form". Hide the second level and when the third level closes, the second level reopens where it was. When the second level closes, the first level reopens where it was.

Great, thanks for the explanation. I just still can't believe that there is no option in settings somewhere to treat those forms like other ones (except when in modal). My code mimics this, but I would prefer the native solution.
 
If you have both a standard & a popup form open with the focus on the popup, Access will again return the name of the standard form.
As you have seen, setting the forms as modal doesn't help in this respect.
The same applies to popup reports
.
This also explains why you can't get certain events to fire on popups
Exactly.
I had a similar conversation with a member of the Access team a couple of years ago suggesting the need for an ActivePopupForm/ActivePopupReport property. He agreed in principle and IIRC posted it as a suggestion on the Feedback Portal though I can't find it now. Suggest you post the same request on the Feedback Portal and if its popular enough, it may get implemented.
That would be great.
For info, I use popup forms whenever I hide the Access application interface.
It works well but you need to be very careful to always reference forms by name for the reasons stated above.
That is why I want to avoid this behavior, because I have too many forms and reports.

Anyways, as Pat said, and you pointed here, there is no native solution. As I replied to Pat, my code mimics normal behavior, but I would prefer the native one.

Thanks
 
you may also try to pass the name of the Calling Form (as OpenArgs) when you open a form, ie:

Code:
Private Sub Command0_Click()
DoCmd.OpenForm FormName:="Form2", WindowMode:=acDialog, OpenArgs:="Form1"
End Sub

Form1 is the form where command0 button resides.
then save the openargs so that later when you close the form
you can Setfocus to the Calling form.

see this demo and open form1.
Can't use dialog, user needs to be able to interact with several windows at once. Also, I already have a code that mimics the native behavior (when closing form it just calls a public sub that presses SHIFT + F6). I just wanted to know if there is more elegant solution like a setting in current database settings or in access setting.

Thanks for your time and for the suggestion.
 
How are you opening your forms? Do you have code trying to set focus on something? If yes, how? if no, why not?
Via ribbon, via buttons, events... it doesn't matter... the behavior for the popups is ALWAYS the same. You even can't set focus to them because they think that they are always in focus. Isladogs and Pat explained very good why is that. I'm just disappointed that this isn't solved natively.
 

Users who are viewing this thread

Back
Top Bottom