Dual screen conundrum

I have several applications that work pretty much in the same way: a standard Windows window with menus and a toolbar, then the rest of the client area is filled with a %gr area. Usually, the %gr has a callback and a handle and takes a pivot, and so is %pv%`^gr[rgb_colours,user_resize,white] (the rgb_colours being a hangover from when that wasn’t the default). Yesterday I upgraded from a single 1280x1024 display to dual 1920x1080 displays driven by a new nVidia GTX 950 video card. These applications all start in the LH monitor, and GetSystemMetrics returns the dimensions of this. Windows 7 64 bit is in use. In Application A the dimensions of the %gr are set to

      IXRES = GetSystemMetrics(SM_CXSCREEN)*0.95
      IYRES = GetSystemMetrics(SM_CYSCREEN)*0.85 

… and the %gr area fills the client area. The toolbar in this application is made with %bb buttons. In Application B there is a test on the aspect ratio of the screen, and in the case of a widescreen the toolbar is put on the left of the screen (using %ib) with the dimensions of the %gr area sized more or less as above, but with a fixed number of pixels subtracted from the GetSystemMetrics result. Once again, the %gr area is appropriately sized. In this case there is a thin grey surround to the %gr area because it is 3D recessed. Application C is now troubling me. The %gr area is sized as in Application B, and no border is selected. In this case, the white %gr area is requested at (say) 1910x960, and although I get the correct height, I get a %gr area that is only 1690 wide, and to the right of that a grey background infill for the rest, up to the 1910 requested (i.e. another 220 pixels). This application has the option to use %tb or %ib for its toolbars. I have tried both to the same effect. I have tried (fruitlessly) to scale the %gr area myself, including removing the toolbars completely. I had previously tried the application (and the others) on screens of 1280x1024 (XP, 7), 1680x1080 (XP), 1440x768 (XP), 1366x768 (7, 8.1, 10) – all single monitor setups. I have tried using the routine SET_MAXIMUM_DIALOG_SIZE@. I have tried taking out the resize mechanism, and the graphics handle (although they work with Applications A and B). I have checked that GetSystemMetrics returns the right values. Finally, I tried turning off the righthand monitor. In this case, the grey area is only 20 pixels wide, and the %gr has grown to 1890! In the dual monitor case, the eventual result is stretchable across both monitors, but always with that 220 pixel righthand band – the user_resize mechanism in my graphics callback routine picks up the stretched size and shape of the %gr area I have got.. I would very much like to get rid of that band, which in any case is not present in Applications A and B. I have a number of questions:

1. Why doesn’t Clearwin+ give me the %gr size I explicitly requested, and
2. Why has Clearwin+ added the extra grey – and can I command it not to?

3. Why do applications A and B work? (The only difference I can find is that they have LH toolbars - I'm going to try that.
   

Eddie

Eddie

If you could post a small working sample of your app(s) then I might be able to find out where the relevant information comes from, but I do not have a dual display so it may be impossible for me to reproduce the problem in order to fix it.

I'll have a go at cutting the whole thing down, because without the toolbars and perhaps the menu strip it's a lot, lot, smaller, but with them there are oodles of callbacks, and vast numbers of icons. Let's see when I get bored with the more important stuff I'm doing at the moment. perhaps you can drop me a PM as to where to send it.

I have had a dual monitor setup before, but it wasn't so sophisticated as this one. Already I'm hooked, and can recommend a multimonitor setup as a productivity tool. It will operate as one or two monitors in portrait mode too.

Eddie

Hi Paul,

I've had a big think about this overnight. If I cut out all the extraneous stuff, I'm likely to revert to the App A and B situation, and without a multimonitor setup you can't duplicate the behaviour anyway.

Perhaps if you are minded to look at it, you could examine the underlying code to answer the question:

*Under what circumstances does a WINIO@ request to make a %gr area sized at X * Y produce a %gr area with a lesser size in the x coordinate direction? * Armed with that knowledge I can probably produce some sort of a fix.

Eddie

Eddie

I am not sure how to answer your question but I have had a look at the response to WM_SIZE for %gr[user_resize] and %gr[metafile_resize].

The code calls GetClientRect to get the width and height of a window and then redraws the graphics area accordingly. I am guessing that the window handle used in GetClientRect is for the child (graphics) window but I can check this out if this is the kind of information that you need.

Paul,

I'm reluctant to ask for too much here, as Apps A & B work, so it is something I'm doing that is causing the issue.

When I resize the window, everything works properly, and the undersized %gr area resizes. The problem is that the %gr area is initially created less wide than I've requested, and the rest of the client area is filled with background colour (grey in this case).

I think the issue is on initial creation of the %gr as the main window is assembled, and not on resizing.

Eddie

A trick that I sometimes use is to get the program to execute a delayed resize but using the existing size of the window. This is a sort of 'heavy handed' refresh.

First I post a user message (PostMessage) as late as possible (e.g. in a %sc callback). Then in response to the message (e.g. %mg) I get the current size and set the size to the current size.

It is a lot of messing about so it depends on how important it is.

Hi Paul,

That's an interesting approach that I will try. By dint of a great deal of experimentation last night, I discovered that if I take out the [maximise] in the %ww, then I get the %gr area the size I want, but, tacked on to the right hand side of the main window is an entirely superfluous and unasked for band of window background (in btnface, as it happens). This overlaps onto monitor 2, and makes the window typically some hundreds of pixels wider than it needs to be..

Clearly, the [maximise] is in this case reducing the window to fit in monitor 1, by reducing the graphics area as it has the %pv.

Further experimentation this morning showed that I could alter the width of the additional band by playing around with toolbar contents (which contain %ap, and I am aware that that has the potential to wreak mischief), but I have not been able to eliminate it, even by omitting the toolbar complete with its %ap commands, so it isn't the explanation.

I had the idea of making the width of the %gr span both monitors (i.e. 2x1920 minus a bit, so 3820) - and this filled both monitors, but it did displace the %gr down at the top by 16 pixels, which confused me even more! However, I have come to the conclusion that I probably cannot solve this conundrum on my own, and have to simply live with it.

Eddie

Fixed – sort of. Taking your advice, I put resizing and repositioning in the %sc callback instead of maximise, resizing in x to the value given by IX=GetSystemMetrics (SM_CXSCREEN) and in y by IY=GetSystemMetrics (SM_CYSCREEN) minus 41 for the taskbar (vertical positioning and size isn’t particularly critical for me) and positioning to (1,1). In order to get the %gr to fill the window without that odd infill to the right, the initial x value needs to be a little bit more than the monitor width (IX determined as above is OK) but less than the available space deep (IY minus 145 to account for caption bar, menu bar, toolbars, and the taskbar), and then the above resizing works perfectly. If the y value is too big the %gr doesn’t resize well. For my dual monitor setup it worked if I multiplied the initial width request by the number of monitors. GetSystemMetrics (SM_CMONITORS) doesn’t work ‘out of the box’ because SM_CMONITORS isn’t defined in Windows.h I resolved the unwanted space above the graphics area by calculating the vertical offset for %`ap from the pixel height of the toolbars and CLEARWIN_INFO@ ('PIXELS_PER_V_UNIT') instead of letting Clearwin+ work it out. Now to look at the problem with a higher dpi setting! Eddie

LitusSaxonicum,

Would it be possible to get part of you code for 'handling' two monitors. I tried that in the past but did give up. It sound like you are far ahead of me and a helping hand would be great

Regards

Sten Lou

No problem, just give me a while to sort out the code fragments and extract them from all the other extraneous stuff that goes on at about the same time.

Eddie

Did you see my PM (private message)?