MoveSize

And yes, Modal and Popup forms can be annoying.

I have no choice as the forms return data that the calling form needs. Here's an example using the tip to specify the left, top, etc. for the form. The top form was set to 0, 0, while the form three deep in the image was 50, 50. However, looking at the .windowleft and .windowtop returns -6180 and -1200 after opening. I remember this kind of problem many years ago with Access, and I can't figure out why it persists. To do an acDialog form properly, I would need to know where the origin starts, as moving the right side of the Navigation pane will alter it, as does the Ribbon. Grrrr Microsoft.

Remember, (0,0) are the top/left coordinates of your PRIMARY display. I have a laptop which is my primary display and a large widescreen monitor OVER it on an arm. That big monitor has negative coordinates.

^ roughly

It's all on the same display, the primary of my laptop.
To make matters worse, sometimes it starts 0, 0 in the work area of the Access display (right of the navigation pane and below the ribbon), but most of the time based on the Access window (the entire window).
It's this kind of inconsistent behavior in Access that drives me nuts. They've got some code cleanup to do.
It can be worked around with code, a good little topic for a Tech Help.

A final note, my initial work around didn't (work that is). Finally got something to work, in the process I went looking in the popular Access forums for insights. Someone described this "bug" 11 YEARS ago! Really Microsoft?!!!

Yep. Access isn't exactly high on their priority list... which is a shame because it could be a REALLY awesome program if they gave it some lovin'. Well... it is awesome, but it could be awesomer.

I use "tab view" for multiple forms (see picture below) to avoid dealing with form positions.  I know some users prefer overlapping forms, but many users are equally comfortable with tab views, since they are used in many apps nowadays, notably web browsers.   One has to ask: does gaining what could be just marginal improvement to the user interface really commensurate with the complexity you have to deal with in handling form positions and such?

@ Kevin In the image, it says Tams Main Form. Are those all "tabs" on one form? Or tabs from Access with different objects? I tried the tabs in form design, but I couldn't see a way to do a scroll bar, maybe I have to look closer.

Those are interesting forms, very inclusive and complex/complete. Do your users all have a display large enough for all that? Or more to the point, what do they do with smaller displays? Just scroll a lot?

Thomas,

If you need a scrollbar try adding a Page Break.

@ Richard, I'm a bit confused by your display diagram, as it pertains to Access. My version of Access won't let me move a Form to another display, only the entire Access window. If I DoCmd.MoveSize 0, 0 in the secondary display (all of Access there) it will still place the (non acDialog) form in the top left of the work area, not in some position far left and up of the Access Design Area.

Hi Thomas, those are "tab controls," which are on Richard's list of Evil Access Stuff.  But I've used it for years.  Sometimes you need to weigh and pros and cons.  I would rather deal with the cons of tab controls than with those of having to re-position forms.  The forms on my tabs are actually subform controls, and that is why they have scroll bars.  To access each tab's subform, I have to set focus on the tab first.  That is the one inconvenience.  E.g.

     Me.Tab1.SetFocus
     Me.Subform1.Field1 = ....

To your point about display size, all my forms are designed to accommodate the smallest resolution that I want to accommodate, which is usually 1024x768.  So I try limit all forms to 800 pixels in height.  Users in high resolutions can increase their Windows display scale (Start -> Settings -> System -> Display -> Scale and Layout), so the forms will appear bigger.  Some Access developers may try to make "Form resizers" that can adjust form sizes dynamically, but that can get really complex (I've tried).  Again, the advantage from doing that doesn't commensurate, IMO, with the complexity of the work you have to put in.

I usually keep the whole Access application on one screen. You can move popup windows around different displays if you want - but I never do.

@Richard, I just did a test; yes, Access allowed me to move an acDialog form to the other monitor but doesn't allow that for a "regular" form. Now, why would that be?

@Kevin Y. Thanks for the explanation. Sometimes I need to compare two web pages, but it's pretty rare. Then it's easy enough to start another browser and have two windows to look at side by side. However, I do a lot more comparisons in Access, how do you compare with form tabs, without resorting to opening Access again in another duplicate db?

I hope they never get the bright idea to but the VBA editor into tabs, or I'm dead.

I agree with the form resizer techniques, to many things cause complications, like controls that don't resize. Yes Check Box and Radio Button, I'm looking at you!

Tabs in most apps can be easily undocked and docked back, like in a web browser.  Access sorely lacks this feature, which would've satisfied everyone.  If you need two forms visible side by side in Access, you'll have to do just that.  If I were me, I would design the app so the user wouldn't have to compare two forms during data entry, while removing screen clutter in the process.

Normal forms are bound to the inside of the Access app window.

I have a login form that is called via an autoexec using dialog. I want to position it at open of the db (otherwise it gets placed over the Navigation pane, similar to image above). Some very strange things are going on with the origin (me.windowleft = 5940, me.windowtop =-705) . I try to find the origin by doing docmd.movesize 0, 0 and I get an RTE 3270, Property not found.  Makes no difference if the code is in Open or Load. It only seems to be an error when opening the form the first time. Could be some Access initialization problems? Anyone else seen this behavior and know how to work around it?
Access 2021, 64 bit.

For those that are having similar problems with positioning the form at Access startup, or when one form opens another, you may want to see my comment in the MoveSize TechHelp.

@Richard, is there a way to put the link here directly to the TechHelp. If not, maybe an explanation in its own thread?

Yep. Done. See that little gray "link" link at the top of the thread. That's the link directly to that thread. :)