Second Screen

As I am finally moving to a new notebook with a 16:9 screen and my desktop screen is 5:4, I am starting to look at drawing graphics on 2 different types of screen. I have resisted the new notebook wide screen format for a long time !

These will require different layouts and I am wanting to adjust the graphics to suit the active screen. I also am considering the overhead projector as a second screen, rather than a copy screen.

I have taken the RESIZE.F95 example to learn how to resize a graphics screen and shift it between the two display screens. I note that clearwin_info@ ('SCREEN_WIDTH') gives the dimensions of the primary screen, and not the active screen. I want to find out the location and aspect ratio of the active screen. I note that 'GetWindowRect' (which I assume is used by Get_Window_Location@ ?) gives the size of the graphics window. After the graphics screen is relocated and sized to the new display screen, I can use these dimensions to draw to the new screen ? (Do I need to as drawing is wrt top left of active screen ?) I can identify the second screen is in use from the response from GetWindowRect but not the screen dimensions.

In the past I have just dragged the graphics onto the second screen and redrawn, where the aspect ratio allows. I don't appear to need to add 1200 to X to get to the second screen, as the X addreses are local to the application window. I do note that pop-ups appear on the primary screen, rather than the active screen.

In the past I have used i = winio@ ('%ww[no_frame,maximise]&') to select all the screen, but my implementation needs to know the active screen aspect ratio to work well. With the dramatic change in aspect ratio, I now need to address this problem more carefully.

Does anyone have advice on how best to manage the active or second screen.

John

I don't have the answer and I don't have the time to research the matter now but here is a line of old C code that might get you started...

GetMonitorInfo(MonitorFromWindow(hwDefault, MONITOR_DEFAULTTOPRIMARY), &mi);

I have been trying to use the resize.f95 example to learn how to be able to resize the screen so I can shift between different size/aspect ratio screens. In %gr,

1. I have changed 'metafile_resize' to 'user_resize' to try and have the new resized window not be scaled for subsequent draw_line@ calls, and
2. I have provided a Caret (^) and a call back so I can re-draw the screen, when it is resized. I'm still struggeling with the scaling of the screen addressing size for subsequent drawing calls.

I wanted to minimise the frame border by replacing '%ww&' by i = winio@ ('%ww[no_frame]&') Unfortunately this removed the rescale arrow at the edge, stopping the ability to resize the window, apart from minimise and maximise buttons. This also appears to have re-introduced the window scaling, which I don't want. I can no longer draw to the edge of the graphics area?

What I was trying to do was have a graphics window/application that could run as a maximised or resizeable window and remove the frame border to maximise the drawing area. When I select maximise, it will maximise to the active screen size so that I can retrieve the aspect ratio of the graphics area. I also need a call-back for managing resize and mouse moves etc, and have a screen where the call draw_line_between@ can address the pixels and not be scaled, as metafile_resize induced.

Does anyone have some suggestions of how I could achieve this ?

My latest resize.f95 program is:

program resize
   use mswin
   use salf_about
   use com_res
   implicit none
   integer :: ctrl,i
!
   ctrl = 0
   i = winio@ ('%ca[Resize me]&')
   i = winio@ ('%ww&')       ! provide resize
!   i = winio@ ('%ww[no_frame]&')  ! this alternative upsets resize
   i = winio@ ('%pv&')
   i = winio@ ('%sc&',draw_func)
   i = winio@ ('%mi[icon_1]&') 
!
   i = winio@ ('%^gr[grey,user_resize,rgb_colours]&',800,600, test_call_back) 
!
   call Menu_Setup
!
   i = winio@ ('%lw&',ctrl)  ! not needed ?
   i = winio@ ('%hw',hwnd)
end program resize

John,

This may not be what you want, but here goes.

If you use GetSystemMetrics (MSDN) then you can find out how many monitors you have active. The monitors are mapped into a bounding rectangle, and as well as a coordinate system for each, you can have a coordinate system for all of them.

When you move from 4:3 or 5:4 over to widescreen, it is excellent if the objects you want to draw are wider rather than tall, as they fill the screen better. If the other way round, they do not seem to fill the available area very well. For some programs I have found it helpful to determine the aspect ratio, and if it is a widescreen, draw toolbars down the side rather than along the top.

My programs all have a big %gr that has a %pv pivot. I can't get on with metafile_resize, and always use user_resize. At the beginning of a resize, I calculate the scaling parameters for 'fit to screen', and then modify them to take care of any 'zooming'. I found by dint of trial and error that I was happiest if I knew the object coordinates relative to the middle of the screen, and worked out all my pixel coordinates relative to that, rather than working to a corner of the screen (0,0).

Early in the callback that services %gr, I find out if there is a resize event and I find the current %gr sizes. When working out my scale factors, I set a minimum of 1 pixel so that I never calculate infinity. I have a separate routine that does the drawing, and I call that before leaving the callback. It contains the UPDATE_WINDOW@.

       CBR = CLEARWIN_STRING@ ('CALLBACK_REASON')
       IF (CBR .EQ. 'RESIZE') THEN
       IXRES0 = CLEARWIN_INFO@ ('GRAPHICS_WIDTH')
       IYRES0 = CLEARWIN_INFO@ ('GRAPHICS_DEPTH')
       IXRES = MAX (1, IXRES0) 
       IYRES = MAX (1, IYRES0)
       IF (MGR(2) .EQ. 0) THEN ! There is something to draw!!!
       CALL ScrnPLOT ! does the drawing
       ENDIF

I like to have my window maximised on startup, which I do by having the appropriate MOVE_WINDOW@ (to 0,0 or 1,1) and RESIZE_WINDOW@ calls in the callback function to %sc. The size in RESIZE_WINDOW@ is a little less vertically than the screen size to cope with the start bar size, which is different in different versions of Windows, which you can find out with GET_OS_VER@.

       CALL Get_Window_Location@ (Master(1), IX, IY, NWID, NHT)
       CALL GET_OS_VER@ (ID_Platform, Major, Minor)
       IF (Major .LE. 5) THEN
           Minus = 0; ELSE; Minus = 12; ENDIF
       CALL RESIZE_WINDOW@ (Master(1), NWID-12-Minus/4, NHT-Minus)
       CALL MOVE_WINDOW@ (Master(1), 1, 1)

MASTER(1) is the handle for the main window. There's a little jump on startup while the empty main window resizes. My redraws are very quick, and I redraw frequently.

When I spanned across multiple monitors, I was unhappy with the result, as dialog boxes would sometimes be split across the screens. If you want to have a control panel on one screen and your main graphics work area on another, and you are programming for your own use, you can hard-code the dimensions. If programming for other users (and who knows what their setup will be?), it's a bigger job. Having two live Windows, one for each screen, is a halfway house, but it is irritating to have the double step of giving a window the focus before you can do anything in it.

Regards

Eddie

Eddie,

Thanks very much for your comments. It will take me some time to understand what you have provided.

I have been making progress, although the latest is a bit of a puzzle. If I use %ww& and user_resize, then when I resize the screen, calls to draw_line_between@ work ok. However if I use '%ww[no_frame]&, I have to subtract about 6 from the returned screen_width = clearwin_info@ ('SCREEN_WIDTH') (and depth) to get the size of the available graphics window. I hope the 6 does not vary too much with different screens. I'm not sure why this happens as with the frame edge, returned screen_width and screen_depth are correct.

My next attempt will be to plug the (5:4) screen into the new notebook (arrived today) and confirm I can recover the correct aspect ratio for each screen.

As for the suitability of the aspect ratio, 16:9 does not suit my layouts for a key program. Even with 1600 x 900 pixels, 900 is not enough, so I'm presently hoping I can plug in a second monitor with at least 1050 lines and run the graphics on it.

John

John,

In my first code fragment, I got the graphics width and depth from CLEARWIN_INFO@. If you use these, they give you the size of the graphics area. If you ask for the size of the Window, then you have to make allowance for the frames, which is where your 6 pixels comes in. The size of the frames depends on your %ww and/or %sy options. It looks like you haven't yet discovered that you have to subtract a lot more in the vertical direction! These frames tend to be the same size for all screen resolutions, but the caption bar depends on the default font height, and so might some other things like toolbars, so getting the graphics area size straightaway solves some problems.

The minimum acceptable screen reso for XP and later is 800x600, and I accommodate things this small by selectively dropping things from toolbars (for example, the text under an %ib icon), and then dropping buttons, to get things to fit. The 124 pixels difference between 900 and 1024 isn't going to make your graphics so much worse, but it will affect the content of any vertical toolbar.

It is a bit of an art designing the main window to be OK under all resolutions and aspect ratios.

Regards

Eddie

Eddie,

The problem I am finding with %ww[no_frame] is that the returned graphics width and graphics depth is wrong by 6 pixels. This is not the case with %ww I have modified resize.f95 to

• return the window dimensions, via GetWindowRect ( api call ?)
• return the graphics width and depth via clearwin_info@
• return the screen width and depth via clearwin_info@ I then draw borders to confirm the graphics size, which identified the problem.

The good news is I have now tried the program on the new notebook (fantastic resolution) and connected a second screen.

With the window maximised on the notebook screen, it is reporting window rectangle -3 -3 1923 1083 ( note the extra 6 ??) rectangle is 1926 x 1086 screen_ .. is 1920 x 1080 graphics_.. is 1926 x 1044 (is + 6)

With the window maximised on the second screen, it is reporting window rectangle 1917 -3 3203 1027 rectangle is 1286 x 1030 screen_ .. is 1920 x 1080 (is primary screen) graphics_ ..is 1286 x 988

If I remove no_frame, the apparent 6 pixel 'error' does not appear. I do not think the 6 pixel error is due to the menu and caption allowance, which is shown in the difference between screen and graphics depth. The available graphics window is smaller than reported ?

The GetWindowRect and graphics_.. are returning the active screen, while screen_ is returning the primary screen. RESIZE.F95 appears to have a history, with DBOS routines and some undocumented calls, eg GetWindowRect.

I am now finding the problem I have been having with vertical resolution is related to my text size selection. I need to check my scale selection, as it appears it has been wrong for years !!

John

John,

Further info: doesn’t “no_frame” imply fixed size? If you just want the client area to show (like a game, or as MS puts it, “an immersive application”), then your %ww needs “super_maximise” and an accelerator key to return the window to “frame visible” shape. There is a standard callback for “super_maximise”, so you can hang that on an accelerator key like F11 with:

I=winio@(‘%ac[F11]&’, ‘super_maximise’)

But your “restore window with frame visible” hot key needs a callback with a RESIZE_WINDOW@ (I think).

I don’t know yet about your 6 pixels.

Eddie

Eddie,

What I want from 'no_frame' and what I get are two very different things.

'%ww&' provides a resizeable window with a border around the graphics area, wasting 48 pixels horizontal and 86 pixels vertically.

I wanted '%ww[no_frame]' to minimise the size of this border region, (say like notepad) but still provide a resize option. My experience is that the border is minimised to the extent that the edge zone where the resize arrow should be is lost. (could be the 6 pixel issue) When the window is maximised, both call GetWindowRect (hwnd, wrect) and i = clearwin_info@ ('GRAPHICS_WIDTH') report a window width that is greater than i = clearwin_info@ ('SCREEN_WIDTH')

If I look at the window provided inside NOTEPAD, the border is minimal, but the resize capability still exists.

I'm still puzzled why I lost the resize arrows with no_frame, when I did select user_resize in %gr.

Maybe I need a '%ww[no_border]' option.

I'll send you a copy of my latest version of resize.f95, which is now too big to list on this forum.

John

As another question, I'm always puzzled by the order of the %.. calls. I always copy what is there but I've found little direction as to when the order is important. The order provided is %ca %ww %pv %sc %mi %^gr %mn %lw %hw although could it be %ca %mi %ww %sc %pv %^gr %mn %hw ? %lw appears unnesecary and is %pv only required for %gr ? too many questions !!

Generally speaking, formats that describe the window can be presented in any order but formats that introduce controls within the window must be ordered unless you use something like %ap or %di to speciify the position of the control.

%lw is used when you want to leave the window open (a modeless dialog) or when you want to control its closure from elsewhere.

%pv provides for resizing but built-in resizing is only provided for a limited number of controls, %gr being one of them.

Hi John,

%pv must come before the control that changes size when you resize the window, in this case (As Paul says) %gr. You have a couple of things in between, but they don't matter in this context, as one of them is the minimise icon %mi which obviously isn't part of the resizing.

You are probably right about %lw, although it does give you another way of closing the application window.

I honestly feel that you are mistaking the 'frame' for the 'border', and what you really want is 'no_border' not 'no_frame'. As the resize arrows operate on the frame, they have to disappear with no_frame, no_border simply positions the %gr area right up against the frame.

This is the simplest I can get it!

      PROGRAM E
      INCLUDE <WINDOWS.INS>
      I=WINIO@('%ca[Eddie]%ww[No_border]&')
      I=WINIO@('%pv%gr[grey]',200,200)
      END

To save me having a callback I haven't made %gr resizable.

Regards

Eddie

Eddie,

I can't believe the mistake I did make. I have looked at the %ww documentation a few times and never saw the no_border option. May be I never scrolled down. Even the example is probably what I want. I will try out a few of these alternative options and see what works best. Hopefully no_border will leave the resize frame and fix the 6 pixel problem also. I think I have enough functionality to solve what I need, without getting the size of the second screen.

Thanks for your help.

John

My apologies also for not answering the question you asked!

Sometimes we need a diagram that says such things as 'this is a frame, and this is what it does' and so on.

I've read the Clearwin documentation loads of times, and there are still things that crop up I've never seen before. In particular, the Clearwin.enh enhancements file is worth a read. Also, the Clearwin book (now online) not just the FTN95.Chm file. I also recommend Windows User Experience Interaction Guidelines on MSDN.

Eddie

I have now got resize working sufficiently. I have also managed to better understand the associated %gr and %ww calls and provide my example should it be of use to others. The basic program is: program test ! use ceasap_variables ! ! include <clearwin.ins> include <JDC_menu.ins> ! integer4 :: i, hwnd integer4 mouse_back_func, plot_setup_func, OnMouseWheel external mouse_back_func, plot_setup_func, OnMouseWheel ! integer4, parameter :: WM_MOUSEWHEEL = Z'020A' ! character build_stamp30 logical full_screen ! full_screen = .false. ! .true. ! ! Initialise for no greyed options ! call crtstart ! this is called again in plot_setup_func ?? ! include 'build.ins' caption ='GHD STRUCTURES SUITE : FEA MODEL : Build date '//build_stamp ! i = winio@ ('%ca@&', caption) ! if (full_screen) then i = winio@ ('%ww[no_border,maximise]&') else i = winio@ ('%ww[no_border]&') end if ! i = winio@ ('%sc&', plot_setup_func) ! call saplot initialisation function i = winio@ ('%pv&') ! i = winio@ ('%`^gr[grey, user_resize, rgb_colours, full_mouse_input]&', & 800, 600, w_handle, mouse_back_func) ! i = winio@ ('%mg&', WM_MOUSEWHEEL, OnMouseWheel) ! mousewheel response ! call Saplot_Menus ! i = winio@ ('%hw', hwnd) ! return the handle of the current window. ! end program test

This provides support for resize and the mouse wheel, via 2 call backs. When the RESIZE callback is initiated, the mouse_back_func calls 'Set_Window_Size' which reviews the graphics scale for the program and the graphics libraries. I use a menu command for the redraw, as there are many ( a lot !) RESIZE interrupts, including at startup. I've also moved out all %mn calls to near the menu definition code. The mouse wheel also provides 2 interrupts. mouse_back_func receives 'MOUSE_WHEEL', while OnMouseWheel receives 'MESSAGE_HOOK' This is an interresting response I have not previously understood.

I have noted statistics from the call-back reasons, from the 2 possible call-back routines

 Callback Statistics : number of interrupts
      Callback reason                    mouse     wheel
   1  RESIZE                                28         0
   2  MOUSE_MOVE                           846         0
   3  MESSAGE_HOOK                           0        10
   4  MOUSE_WHEEL                           10         0
   5  MOUSE_RIGHT_CLICK                      2         0

I hope this is of use.

John

Hi John,

The code you posted is very straightforward.

I found that if I wanted my program maximised on startup, I had to give x and y sizes for %gr that filled the frame, otherwise I got a grey border that took precedence over the graphics area on resizing (i.e. was always there). I based these on the screen size minus a bit in x and y that I discovered by trial and error*. (You have explicitly declared 800x600). What I then discovered was that the frame size is different between versions of Windows. Also, in the vertical axis, the caption bar + my toolbars + the Start bar at the bottom of the screen also varies between Windows versions. (It also varies depending on the “large fonts” setting).

As some events such as resize aren’t mouse events as such, then for clarity, maybe the word “mouse” shouldn’t be in the callback routine name?

You get loads of callbacks because you have full_mouse_input – we had a discussion on this in the past. Is it not the case that the mouse_wheel callback needs a different “callback reason” because it may not be associated with the %gr area, and if the %gr doesn’t have the focus, the mouse wheel operation wouldn’t generate a callback? If you use the mouse wheel to resize the Window, you lose the extremely handy alternative to zoom the contents of the %gr area, as users normally don’t get the hang of giving the %gr area the focus first, and the behaviour becomes non-intuitive as it is different to other Windows applications.

I also commend putting all menu instructions in a separate routine. I use separate routines to set up toolbars. So that all my windows have a common appearance, I also put %sy, font information, colours etc in a subroutine. All my accelerator key settings go in another. And so on. At one stage, I found some quite funny behaviour on closedown, which was eventually solved by explicitly using SAVE in each of these constituent routines. I put this down to me still programming in traditional style. Maybe with MODULEs you don’t have to.

Eddie

*This trial and error process for me is either grabbing the screen, copying into Paint, zooming in and counting pixels, or using “Ruler by George” to measure things directly on screen.

E