Share via

Pop up window positioning

Anonymous
2011-12-06T01:12:55+00:00

On SVGA screens my Access 2003 application has always been opened in a maximized screen.  However, many people running Windows 7 on modern wide screen monitors open applications in partial windows and then they move the window.  This creates a problem for pop up windows that are programatically positioned to appear in an exact location over top of another window.  When the user moves the window, the pop up doesn't move with it, whether it's modal or not.  Is there a solution to this problem?  Do the windows behind the pop up also have to be programatically postitioned, or is there a better way to deal with this?

Microsoft 365 and Office | Access | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

Answer accepted by question author

Anonymous
2011-12-13T02:16:17+00:00

I appreciate you following through on this thread.  Could you clarify your last statement?  When I open a window for this purpose I don't want it to remain open on the screen once the user has made their selection of data.  Are you saying that I could/should disable the PopUp property of the same form I'm using now and essentially still use it in the way I am now?

 

I don't see why not.  Bear in mind, of course, that I don't know all the details of how you're using the form now.  But I assume that you open the form from another form, the user makes some sort of selection, and then some event causes code behind the form to transfer data to the original form and close this one.  None of that requires this form to have its PopUp property set.  You may possibly want to either open the form in dialog mode, or have its Modal property set, but I don't think the PopUp property ought to be required.

Why don't you experiment with the way the form behaves without its PopUp property set, and see what difference it makes?  If it doesn't behave the way you want, then let's consider how to address that problem.

Was this answer helpful?

0 comments No comments

9 additional answers

Sort by: Most helpful
  1. Anonymous
    2011-12-09T18:28:01+00:00

    This discussion is academic now I guess, but that was exactly my point.  Why did MS not confine the Access popup window within the Access application window?  Why wasn't it made a child of the application window?  It makes no sense for it to be a child of the desktop when it's a window opened from within an access application.  This IS something bad that MS did, in my opinion.  When a less-than-maximized window is moved and all windows of the Access application move with it except the popup, which is part of the application, that's just plain dumb.

    I guess I'll adjust my Access application to not use popups.  It's unfortunate that popups are essentially useless because of this, unless you go to great lengths to add code to modify their positioning.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2011-12-09T02:13:54+00:00

    Why in the world did MS do this?  Is this true in newer versions of Access?

    Yes, it's true in all versions of Access.  Your question, "Why did MS do this" makes it sound like something bad that Microsoft did, but really, that's what a popup window *is*;  if a window is not to be confined within the Access application window, it can't be a child of the application window.  So it has to be a child of the desktop.  In order to provide the full functionality of the popup window, with its ability to be placed anywhere on the desktop, there's no other way to do it.

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2011-12-09T01:52:53+00:00

    Dirk,

    Yes, you are understanding my issue correctly, and you have enlightened me.  I didn't realize that popup windows are children of the desktop and not the Access window.  That definitely explains what I'm seeing.  Why in the world did MS do this?  Is this true in newer versions of Access?

    I don't think it's worth my time to try to make this work, even using the class you refer to.  I guess I'll just instruct users to run the application in a maximized window and leave it that way.

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2011-12-06T02:51:34+00:00

    On SVGA screens my Access 2003 application has always been opened in a maximized screen.  However, many people running Windows 7 on modern wide screen monitors open applications in partial windows and then they move the window.  This creates a problem for pop up windows that are programatically positioned to appear in an exact location over top of another window.  When the user moves the window, the pop up doesn't move with it, whether it's modal or not.  Is there a solution to this problem?  Do the windows behind the pop up also have to be programatically postitioned, or is there a better way to deal with this?

     

    When you refer to "partial windows", do you just mean a non-maximized window?  Am I right in understanding that your issue is that users move the application window, and the popup windows don't move correspondingly (because they are children of the desktop, not of the Access window)?

    I don't think that Access provides any event that will tell you when the application window has been moved.  However, the popup form could use its Timer event to check where it is positioned with respect to the application window, and could then move itself accordingly.  This seems a bit cumbersome to me, but it should be possible.  Nicole Calinoiu's FormWindow class (http://access.mvps.org/access/forms/frm0042.htm) provides a handy way to get and set window positions and sizes, though you may have to make some adjustments to work with the windows that are children of the desktop rather than the Access MDI client window.

    Was this answer helpful?

    0 comments No comments