Get WindowDesktopHeight and Width

Lounge (Discussions)
1

I was intrigued as to what Get (WindowDesktopHeight) and Get (WindowDesktopWidth) are doing post FileMaker v15 in WIndows.

The original purpose of these was to provide the size of the MDI window (the grey area that all windows occupied within using Windows pre FMP v16).

As documented now FileMaker Pro 18 Advanced Help it now works on Windows as it always did on the Mac, with slight nuances between Mac, Windows, FMPA, FM Go and WebDirect.

2

It works the same on Win and Mac. There is a catch with multi-screen setups as FMPA does not distinguish between screens. This may lead to new windows opening on the wrong screen, if no workaround is applied.

3

Hi Torsten, you’re right, unless you are using pre v16 on Windows, as mentioned above.

I haven’t used this for years, but certainly it (v18) does recognise different resolutions on a 2 display setup, if you drag the FileMaker file between them.

Kind regards

Andy

4

@AndyHibbs, for FM, a two-screen setup looks like one big single screen. It also does so, when the screens have different resolutions and geometries. Same on Win and Mac.

Attached is a sample file. Hit 'Update' after moving the window to a new position on any of the screens.

Regards
Torsten
Screen.fmp12 (176 KB)

2 Likes
5

Hi Torsten

I think we're right here. I only mentioned the screen resolution, on your example the Screen W/H on my MacBook Air reports 1440/900 and 1920/1080 on my 1080p monitor as expected.

The Y/X parameters are as you state, with the X parameter recording the pixels from the left most screen regardless of the screen the file is positioned within and the Y parameter doesn't change, as it is reporting the height of the largest screen only.

Interestingly, you've used Get (ScreenWidth)/(ScreenHeight), which are subtly different to Get (WindowDesktopHeight)/(WindowDesktopWidth), which should report the usable height and width.

However, the results of this were inconclusive during my (very quick) tests. The MacBook screen reported an 877px height, allowing for the menus and dock, but when on the 1080p file it still reported the same results as Get (ScreenWidth/Height) despite the dock being at the bottom of the screen. It did make an adjustment if I put the dock on the left, of 1893/1057, but repositioning the the dock to the bottom of the screen resulted the full 1920/1080 result. Very inconsistent (and inaccurate).

A growing bugbear of mine is the lack of testing all software vendors do on dual display arrangements, particularly for Mac, where MacBooks are so often connected to a second display. We've been working with Microsoft for a couple of years now optimising Microsoft Remote Desktop to run FileMaker, particularly since the move from MDI to SDI and we've hit many similar situations.

Thanks for putting the file together.
Andy

6

thanks to Torsten I had a basic file to throw some MBS-stuff in to get more data
the extension brings info on:

  • where the window is located (first, second, third screen)
  • where the screens are located in relation to the first screen
  • comparison of desktop measurement FM to MBS espacially on dock height
  • can be customized with more calculations...

have fun :slight_smile:
Holger

Screen_v2.fmp12 (188 KB)

PS. : functions/calculations where started because I wanted to see whether the window is shown on a beamer...

2 Likes
7

@harvest, thanks for extending the sample file! :grinning:

8

Hi Andy
The sole application on my computer (Mac), that does not handle multi-screen setups properly is...FileMaker.
I can cope with it in development. For user GUIs workarounds are required in order to prevent new windows eventually popping up in the wrong place.

9

Torsten, you’ve just nailed it, we use a ‘Workaround Innovation Platform’. :joy:

5 Likes