%gr sizing to full width of window

Hi. I'm having some fun trying to get a %gr control to completely fill a resizeable window. The %gr follows a %pv and has the user_resize option, and the window also contains menu, toolbar and a status bar. This is a program that has been around for years, but the advent of 4k and high-dpi displays has highlighted a problem.

Up until now the %gr has been given a size that makes it the widest control, so the window sets its width based on the gr. I'm now finding there is a gap to the right of the gr when Windows font scaling (dpi) is increased. I guess this is because the fonts used in the status bar, title etc. have increased in size and make the title and status bar wider than the gr, hence the gap. The quick-fix is to increase the size of the gr, but I can't just have a fixed number any more as the range of possible screen resolutions & dpi settings is too large. I've fudged it for the moment by scaling the gr width based on the system dpi value, but I'm not entirely happy with that. Is there any way to tell the gr to fill the window, or maybe a way to set the gr width after the window has been created so ClearWin can lay out all the other controls first?

Here's a small example - running this at normal Windows '100%' scaling (96dpi) the gr fills the window. Up the Windows scaling to '125%' and a gap appears between the gr and the window edge:

winapp
  use mswin
  integer i
  character*48 title   ! length affects window width
  external draw
  
  title = '%gr User Resize Test'
  i = winio@('%ww[no_border]&')
  i = winio@('%ca@&', title)
  i = winio@('%pv%^gr[blue,user_resize,rgb_colours]&',500L,500L,draw)
  i = winio@('%ob[status]%`48rs%cb', title)
end

integer function draw()
  use mswin
  integer x,y,resize

  resize=clearwin_info@('GRAPHICS_RESIZING')
  if(resize .eq. 1)then
    x=clearwin_info@('GRAPHICS_WIDTH')
    y=clearwin_info@('GRAPHICS_DEPTH')
    call draw_line_between@(10,10,x-10,y-10,rgb@(255,0,0))
  endif
  draw=2
end function draw

You can find the size of the screen by using this routine:

    IXRES = GetSystemMetrics(SM_CXSCREEN)

(and similarly for Y)

Set the size in %gr accordingly after experimenting with how many pixels to subtract for borders, menus, toolbars. Oddly, I found adding a few to the X dimension was helpful in wiping out the bit I didn't want, but you subtract some from Y. The pixels taken by menus varies depending on the default font, and thus between different versions of Windows. In my case I often do without the toolbar if IXRES <801 (those 10' netbooks) or put it down the side instead of across the top if the screen is widescreen format.

This trick doesn't work if the computer is widescreen but connected to a non-widescreen projector, as Windows tells you the native size of the system monitor!

Eddie

Sounds like a good plan and you can get the widths of other window elements from GetSystemMetrics too. I'd be a bit concerned about multi-monitor setups and any other unexpected Windowsy things.

For my app I've ended up creating a dummy window off-screen at startup with the same key elements that dictate width, then using GetClientRect in the start callback to get the actual size. The dummy is then closed and the proper one created using the client rect dimensions to set the gr.

What would be great is a simple clearwin function to change the size of a gr after creation...

Alan

Yes, that defect/annoyance has to be resolved somehow.

Multimonitor systems are a pain, because if you don't tell Clearwin@ where to put a dialog box it is put slap on the overlap.

The issue only arise sif you want maximised on startup.

Eddie

Is there an easy way to control where the dialog box or pop-up box will appear? I sometimes find that if I am working on the second screen, the dialogue or pop-up will appear on the other screen and I don't know why the program is not responding !!

John

It depends on the context but you may be able to use %sc and %hw together with MOVE_WINDOW@.

Hi John,

You can set the position of a dialog box with %sp, and get its position with %gp. Using the latter on closure of a dialog box gets you the coordinates to position it where you had it last time. There is a thread somewhere on the forum with you and I discussing managing 2 windows - this only relates to dialog boxes - for popup menus Paul said he'd look at it in June last year.

In my view, a popup menu should appear on the same screen as the point that invoked it.

Eddie