Access 2019 overlapping windows

Question

Is there a keyboard shortcut to navigate between overlapping windows in Access 2019? If not, there should be.

Answer 1

As with all MDI (multiple document interface) applications in Windows, Ctrl+F6 cycles between them.

Answer 2

Given that the ribbon does have the beginnings of the functionality you want, you probably could use VBA to create a function to do the same thing and assign that to a macro for a shortcut. Moreover, your question made me think more about interface design.

I think that most Access developers probably tend to think in terms of either a menu or the ribbon as the way they want users to interact with forms and reports, etc. So, our design efforts go there first, and having a short cut key just to cycle through any windows that happened to be open at that moment in Access would not be something that would come to mind immediately. It's more of a developer function, I think. On the other hand, if you are working on a form, a query and maybe a report that need to be synchronized, for sure being able to cycle through them would be handy.

From that point of view, the ROI of creating and implementing the code for such a shortcut key probably has more to do with your convenience as a developer than for an end user, which is where most of our attention actually goes. But even then, then are tools -- such as MZ Tools -- to automate a lot of the coding tasks, so there's probably room for something like this.

Answer 3

I found the Switch Windows drop-down in the Window Group that lists all open Windows.

So, probably no keyboard shortcut; just have to use the mouse. Windows are stacked and the choice for the next window would be the next one down in the stack, but a shortcut key combo could quickly move through any number of Windows with repeated keystrokes. I like having many ways of doing the same thing depending on what my hands are doing at the time. Thank you for your reply. Most of the time I am too quick with my questions. I should take my time to explore Access more before asking questions. Most of the time I can figure my problems out for myself but not immediately.

Answer 4

Most of the time I am too quick with my questions. I should take my time to explore Access more before asking questions. Most of the time I can figure my problems out for myself but not immediately.

Hi Clifford,

I like these kind of questions, so please continue. It makes me think on how I would handle these questions.

As I am a touchpad user, I never need to catch the mouse, and a RightButton-click is for me as good as a shortcut key. Or even better, because the RightButton-click is already in the right context, and the equivalent shortcut key I must remember.

My users hardly use shortcut keys. They don't like to remember all those cryptic combinations. They can always "read" in menu-like forms what to do next, with only the actions they are authorized to perform, nothing more and nothing less.

I never use Ribbons. The functionality for Forms or Controls, etc, is build in in the Forms or the Controls. All kind of functionality, mostly outside the scope of a form, as "show the open forms" (button "Form_stack"), is gathered in a menu-like "Taken"-form. This kind of functionality is mainly for development, but is filtered depending on user and context.

Clicking on "Form_stack" opens a form with the names of the open forms, but also additional buttons to manipulate the appearance or functionality of a form. Such as to give a form the focus (in case there are no modal forms).

As an example I show the unfiltered "Taken-form":

The nice thing of this all, is that the "Taken-form" is standard in all of my applications.

Imb.

Answer 5

Interesting idea. I wonder if someone could create a function to do that. It would require a method to identify which window the user intended to navigate to next. That's the first hurdle. After that, though it would be pretty easy to set focus to that window, though.

A lot of things that people think would be handy probably don't get implemented, though, because other functions are more practical and fundamental to successful interfaces.

By the way, what have you tried so far? Oh, and how would you make that choice of "the next" window to switch to?