Proper focusing of windows in MS Access (natively or by a code) (1 Viewer)

mldntodorovic

New member
Local time
Today, 19:42
Joined
Jan 17, 2025
Messages
1
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

Users who are viewing this thread

  • Back
    Top Bottom