Quickwin appears incompatible with Win 8.1 re screen resolution

[dboggs]

My Quickwin programs feature project frame and child windows that have been carefully sized and positioned on the screen, with automatic detection for maximum screen size and appropriate adjustment when the exe's are run on various hardware setups. The programs were developed on XP and Win7.

I now have a Dell Venue 11 Pro running Win8.1. The window sizing and placing fail on this computer. They are generally too big; e.g. a project frame that is supposed to occupy say 0.9 of the screen width and height appears too big to even fit on the screen. This happens even when I build the program on the Dell.

I have traced the issue down to this. The windows screen utility claims that the screen resolution is 1680 x 1050. But the info returned by Quickwin function GETWSIZEQQ (QWIN$FRAMEWINDOW, QWIN$SIZEMAX, frinfo) returns frinfo%w = 1344 and frinfo%h = 790. If I code my program to create a window say 1200 pixels wide, I would normally expect it to occupy 1400/1680 = .83 of the screen width, but in fact it occupies 1400/1344 = 1.04 of the width--iow, it won't fit. It is doing what Quickwin tells it, but it no longer matches the screen's physical characteristics like it did in the past.

So evidence points to the screen having significantly fewer pixels than what Windows (or Dell) claims it has. But maybe the problem is just Quickwin: is it trying to draw everything using pixels that are bigger that what is on my screen?

Why doesn't the info returned by GETWSIZEQQ match the info returned by the Windows screen properties tool? It has always matched on my previous systems.

[TimP]

As you don't answer the first question which occurs to me, I'll assume that this behavior refers to the laptop's touch screen, and an attached non-touch monitor might not arouse your objections.  Next, I assume that you could smudge the window opened on the touch screen to make it fit as you prefer.

I suppose, if QuickWin isn't touch screen aware, it knows only about a virtual screen and not how it is mapped physically.  It's not only within QuickWin that it's nearly impossible to have windows behave when switching between touch screen and traditional monitor.
 

[Paul_Curtis]

Your issue has little, probably nothing, to do with the Windows version.  I have no idea what GETWSIZEQQ does, but you should instead directly use the WinAPI function GetDeviceCaps to discover the actual pixel extents of the active monitor hosting your app's window:

[fortran]

! Get the display limits
hdc = GetDC (hwnd)
wScreen = GetDeviceCaps(hdc, HORZRES)
hScreen = GetDeviceCaps(hdc, VERTRES)
retval = ReleaseDC(hwnd, hdc)

[/fortran]

[andrew_4619]

I'm sure we have been here before....

GETWSIZEQQ returns the size of the client area of the window  not the size of the screen

I use:

use ifwin, only:  SINT, GetSystemMetrics, SM_CXSCREEN, SM_CYSCREEN
integer(SINT)     ::  iwid, iht !display size
iwid = GetSystemMetrics(SM_CXSCREEN) !pix width of primary display
iht  = GetSystemMetrics(SM_CYSCREEN) !pix height of primary display

[dboggs]

If you call GETWSIZEQQ as I showed it (using QWIN$SIZEMAX as an argument, it will return the largest possible window size to fit the entire screen. This is pretty standard usage, and I do it all the time.

To Paul Curtis: GETWSIZEQQ is a Quickwin routine. As such it is simply a wrapper around API functions, Don't know which ones (that's why people use Quickwin--so they don't have to know), but probably the same ones you show. The Quickwin routine is even more convenient because simply by varying a couple of arguments it will do several different things.

To Tim Prince: I run a second monitor but so far only as a shadow of the tablet screen. Both show exactly the same thing. Of course this is not a very complete test and I will experiment further. But no matter what it shows, I have to wonder why the program inquiry returns a different result than the Windows inquiry.

[Neels]

GETWSIZEQQ is a Quickwin routine. As such it is simply a wrapper around API functions, Don't know which ones (that's why people use Quickwin--so they don't have to know), but probably the same ones you show.

I agree with this very much - I dislike being told to use some API function to solve something. I use Quickwin and do not have time to learn the API functions or programming!

Neels

[Steven_L_Intel1]

app4619 wrote:

I'm sure we have been here before....

GETWSIZEQQ returns the size of the client area of the window  not the size of the screen

I use:

use ifwin, only:  SINT, GetSystemMetrics, SM_CXSCREEN, SM_CYSCREEN
integer(SINT)     ::  iwid, iht !display size
iwid = GetSystemMetrics(SM_CXSCREEN) !pix width of primary display
iht  = GetSystemMetrics(SM_CYSCREEN) !pix height of primary display

This in fact is exactly what GETWSIZEQQ is doing - I looked at the code. I note that MSDN says:

The width of the client area for a full-screen window on the primary display 
monitor, in pixels. To get the coordinates of the portion of the screen that 
is not obscured by the system taskbar or by application desktop toolbars, 
call the SystemParametersInfo function with the SPI_GETWORKAREA value.

This is all an area unfamiliar to me, so I'm not sure if GETWSIZEQQ should be doing something different.

The comments in the routine say it is subtracting for the height of the client toolbar, and it does seem to do that, but I don't spot the actual code doing so. Hmm..

[andrew_4619]

@steve #7 the snip I quoted does give the actual screen screen size as I have just verified looking at the display properties (control panel).

http://msdn.microsoft.com/en-gb/library/windows/desktop/ms724385(v=vs.85).aspx

SM_CYSCREEN 1

The height of the screen of the primary display monitor, in pixels. This is the same value obtained by callingGetDeviceCaps as follows:GetDeviceCaps( hdcPrimaryMonitor, VERTRES).

The height and width returned for a frame window reflects the size in pixels of the client area excluding any borders, menus, and status bar at the bottom of the frame window. You should adjust the values used in SETWSIZEQQ to take this into account.

From User and Reference Guide for the Intel® Fortran Compiler 14.0

[Steven_L_Intel1]

I know - I built a program that calls GetSystemMetrics and GETWSIZEQQ and compared them. What I am puzzling over is that I don't see where in the GETWSIZEQQ code it actually adjusts for the taskbar size. I must be overlooking something. I also note that it doesn't matter whether one is using MDI or SDI mode, The widths returned are the same, just the heights differ. I will have to try this on a Win8.1 system (mine is not touchscreen) and see if I get different results.

[dboggs]

I thank everyone for the above discussions. It helps and is very useful.

But as it turns out the real answer to my initial concern is totally unrelated, and is instead a new "feature" of Win8.1 that is, to me, quite bizarre. If you "personalize" the screen (a control panel op that is usually accessed by right-clicking on the screen) there have always been options to adjust the size of various elements, such as title bars, icons, and text. If you make the text larger it generally comes out cleaner, because more pixels are then used to define a character.

In Win8.1 these features still exist but are somewhat harder to find, and instead there is a new option occupying a prominent up-front position in the menu, titled "Make all objects larger" (or something like that). It does this by actually REDUCING THE RESOLUTION. This would be OK, except that if you then use the control panel resolution inquiry it doesn't tell you the current (reduced) resolution, it tells you the original full resolution! So it appears that the current resolution and the control panel report are in conflict.

When you use Quickwin or API functions to inquire the screen resolution, they (correctly) report the reduced resolution, i.e. as it may be affected by your "make all objects larger" setting. This is as it should be.

At the time of my original inquiry, unbeknownst to me I had changed the setting to "make all objects larger" thereby reducing the resolution. This is why all of my drawn objects, including windows, no longer fit on the screen.

Once you understand how the system works, it is easy to deal with it.

[Paul_Curtis]

I would point out that the OP's two statements outlining his programming philosophy -- "that's why people use Quickwin--so they don't have to know" and "once you understand how the system works, it is easy to deal with it" are inconsistent, to say the least.

It's disappointing to provide an actual concrete (and correct) answer to a question, and have it rejected for reasons that appear to be religious rather than technical.

[Steven_L_Intel1]

GETWSIZEQQ should return the correct pixel dimensions, so even if there is another way to do it, it is useful to understand what is going wrong. Yes, Windows 8.1's response to the very high resolution screens coming out is to offer to reduce the resolution, so that on-screen elements are bigger. This is because most Windows applications use fixed-size elements and show too small at high resolutions. This is a frequent complaint about newer Windows devices.

[dboggs]

Paul, I didn't really reject your advice, but please note it proves to be irrelevant to the original problem. The culprit is that a control panel option (make objects larger) surreptitiously reduces the resolution, while another control panel feature (screen resolution) continues to report the original resolution instead of the reduced resolution. Once you know not to trust the screen resolution report provided by Windows, and istead inquire it programmatically (whether by Quickwin or API is immaterial), it then becomes a simple matter to code for the actual resolution. 

[Neels]

Paul,

My reply was not aimed at you but rather towards Intel that does not seem to add any functionality to QuickWin. I am an engineer not a programmer and have more pressing requirements on my time and just do not have the time to learn Windows API programming. I always read your replies (and a lot of others) as it is usually very good. My apologies if it came across any other way.

Neels