Here is a single-window sample app (created using PB 2017 R2) that uses the Unicode version of the GetMonitorInfo WinAPI call with either the WinAPI MONITORINFO structure or the MONITORINFOEX structure.

Run the app & position the window in the monitor of your choice, then click either the "Monitor Info From Window" button or the "Monitor Info Ex From Window" button.

John

A bit late maybe, but I just solved a very similar problem. If anyone's interested I can make a small sample application which contains the solution. (indeed based upon windows API's).

It's cost me the whole "$£%^^£$"%l*())*F(F*D()FDF day trying to find out why things did not work:

Always Works!

FUNCTION boolean GetMonitorInfo(ulong hMonitor, ref str_moninfo lpmi) LIBRARY "User32.dll" alias for "GetMonitorInfoA;Ansi"

Never works, always returns FALSE:
FUNCTION boolean GetMonitorInfo(ulong hMonitor, ref str_moninfo lpmi) LIBRARY "User32.dll" alias for "GetMonitorInfoW"

Did anyone manage to get the Unicode version working?

TIA.

Hi Olan, good idea!

Especially in multi-monitor setups.

I actually implemented similar positioning logic recently. Setup was multi-monitor. App used a light custom framework. Functionality included:

• Snap new MDI sheet to edge or corner of MDI area
• Snap new MDI sheet to right edge of MDI area and resize to leverage full height of that MDI area
• Center new response window on top of its parent window

I could generalize (like independent of MDI metaphor), wrap in a self-contained NVO, and share with community via an article acting as documentation? Later extend to snap/center on monitor occupied by particular window? 

Wonder if anyone would leverage such code...

/Michael

I find that popups require far too much effort to position correctly. I would VERY much like to see an enhancement such that the positioning of any window, including a popup, can be specified with simple parameters:

CENTERED                                                  // Centered on the screen; i.e. today's PB default
CENTERED ON PARENT WINDOW
UPPER LEFT CORNER
UPPER LEFT CORNER OF PARENT WINDOW
UPPER RIGHT CORNER
UPPER RIGHT CORNER OF PARENT WINDOW
LOWER LEFT CORNER
LOWER LEFT CORNER OF PARENT WINDOW
LOWER RIGHT CORNER
LOWER RIGHT CORNER OF PARENT WINDOW

// Specify upper left corner of the popup window location on the screen
CUSTOM LOCATION ON WINDOW

// Specify upper left corner of the popup window location on the parent window
CUSTOM LOCATION ON PARENT WINDOW         


Opinions? Thoughts? Additions?

Thanks,

Olan

I don't know if the solution we use is necessarily the simplest; it depends on how comfortable one is calling Windows API functions. 

The first part of the process is to code a CenterOnParent() function in the window that you want centered.  Our windows mostly are inherited from a common base window, so that is where we put the function.  Without that sort of an inheritance hierarchy, one could just as easily create a global function taking two Windows as arguments, one being the parent window, the other being the window to be centered.  The basic idea to center a child window over its parent is to:

• Call the WinAPI function GetWindowRect() for both ParentWindow and the child window to get their size and position on the screen.
• Do the math to center the child window's rectangle over the parent window's rectangle.
• Optional:  To make the function really universal for all window sizes, use the MonitorFromPoint() and GetMonitorInfo() WinAPI functions to determine the bounding rectangle of the monitor on which the parent window is located, and then do the math to make sure that the calculated child rectangle is not going to move past any of the monitors edges adjusting the child window's position as needed.
• Clear the Center property on the child window.
• Move the child window to the new, calculated child window coordinates.  Remember to use PixelsToUnits to get the right coordinate system!

The second part of the process is to write your own Printer Setup window calling in its Open event the CenterOnParent() function.  This is actually pretty easy with the highlights of the process below.

• Use PB function PrintGetPrinters to get a list of available printers.
• Make a DataWindow object to list the printers.  Needs three string columns for printername, drivername, and port.
• Use the DataWindow ImportString() function to populate your DataWindow.
• Call the PrintSetupPrinter() function from Setup button.

Alternatively, one can wait for a subsequent version of PB to include a CenterOnParent property.  This is not a far flung hope as the he PB Window's Center property which is quite handy in a single monitor environment was not always there.

Andy

Hi Marc;

  Yes, any internal or O/S dialogue (like Message Box dialogue for example) will always appear on Monitor #1. You cannot control this aspect.

  Workarounds:

1) Code your own MsgBox, PrintSet-up, etc dialogues and then center them upon open with your App's current location or in the case of PowerServer Web App's, within where the web browser is located.

   FWIW: My STD Framework uses this approach - Including, IWA based Apps.  ;-)

2) Use the FindWindow O/S API call to locate the Handle of PB or O/S dialogues. Using the handle of the Window, you could now under program control relocate it to monitor #2.

  IMHO: This would make a great enhancement suggestion for the PB run-time.

Regards .. Chris