Multiple displays and saving/using coordinates

I'm curious to know how you handle multiple displays and placement of windows/dialogs. Any code you'd be willing to share would be helpful. A specific example:

When I start the program, it appears on the main screen (Display 1). I then drag the window to the alternate display (Display 2) to continue work. As I click options and bring up new windows, they will appear on the primary display (Display 1). What I am looking to do (using MOVE_WINDOW@) is force the window to display, appropriately, on Display 2. Or, if the user has manually moved this window to a specific location (regardless of which display), the window will re-appear at that location the next time it is invoked.

As I see it, there are a couple of stumbling blocks. First, the coordinates of the secondary display are 'unknown'. I see Windows API's that can be used to query the system, and reveal the coordinates and characteristics of multiple displays (one at a time) and that would be helpful. But these routines are not in the WIN32API. It is possible to determine what display is being used assuming the same size display for a multiple display system, and knowing the last window position. And maybe that's all the information needed for the new coordinate calculation.

If %ud (or equivalent) worked on a %ww when the window was created, then I can see a way clear to get this behavior. I can only see this working if a separate set of callbacks are created for each window/dialog that might be created.

Thanks, Bill

I will make a note to look at adding %ud to %ww.

Have you considered using %sc for a startup callback? In theory you can create your own association between %ww and your window data, maybe using %sc on the way.

For the next release, %ud has been extended and here is the outline description as it will appear in cwplus.enh...

'User data (%ud) can now be attached to a window as well as to any control within the window. In this case %ud should appear before any controls are defined. The data can be retrieved via a call to CLEARWIN_INFO@('USER_WINDOW_DATA') (if the window is currently active) or via a call to GET_USER_DATA@ with the (INTEGER(7)) hwnd argument obtained via %hw. SET_USER_DATA@ will also work in this context with the same hwnd value.'

This is great, Paul! Thanks for adding this. It will be great to have global data I can attach to the window itself!

I am using %sc in preparation for adding scrollbars if a window is too large for the physical display. With COMMON to reference my main window, I use its current coordinate when I create the subsequent windows. I have %mv attached to each window so if I drag a window to a different display, subsequent windows will 'follow'. I have yet to determine if this is the best from the user perspective, but it is simple and let's me experiment with various WINIO@() commands and responses.

After playing around with this for a bit, I am becoming confused. I had to add tracing to the %sc and %mv callbacks to find this. I hope this didn't also muck up the timing. Here is the sequence:

1. The main window is created in the primary display. The first call back is the %mv, followed by the %sc, then another %mv.

Each %mv call, if the reason is 'WINDOW_MOVEMENT' saves the current (x,y).

2. I move the window to Display 2 (negative X coordinates). %mv callbacks only.

3. I click the control that opens a new window. First callback for the new window is %mv. But in the midst of the %mv, the %sc gets called, computing the appropriate position of this window in the second display. But when the %mv finally finishes, it's location remains on Display 1.

4. Now, create the next window, and because the last position is on display 1, the window is opened on display 1, not display 2.

I have included the trace with my comments in [color=red:f7f3751597]RED.[/color:f7f3751597]

I'm continuing to work on this but the asynchronous nature is hard to fight.

Window Position Movement (callback):WINDOW_MOVEMENT 723792 -1523 62 1206 799 [color=red:f7f3751597]Last movement of first window[/color:f7f3751597] **** Unrecognized KEY PRESSED=535 (Z:217)[color=red:f7f3751597] This starts the second window on Display 2[/color:f7f3751597] Option selected=0 ***** End of Menu Selection Window ***** Window Start: F[win_icon]C-MASTER (32 BIT) - Choose your desired function Window Position (callback):WINDOW_MOVEMENT 1313838 224 73 1232 905 [color=red:f7f3751597]Start of %mv for second window[/color:f7f3751597] set_my_position (current)= 1313838 WINDOW_STARTUP 0 [color=red:f7f3751597]Start of %sc for second window][/color:f7f3751597] set_my_position (current)= 224 73 1232 905 set_my_position (before)= -1680 0 set_my_position (final)= -1456 72 [color=red:f7f3751597]End of %sc for second window[/color:f7f3751597] Window Position Movement (callback):WINDOW_MOVEMENT 1313838 224 73 1232 905 [color=red:f7f3751597]End of %mv for second window[/color:f7f3751597] [color=red:f7f3751597]Now, the third window gets created, but in display 1 because of the ending of the %mv above[/color:f7f3751597] Window Position (callback):WINDOW_MOVEMENT 1379374 547 414 586 223 set_my_position (current)= 1379374 WINDOW_STARTUP 0 set_my_position (current)= 547 414 586 223 set_my_position (before)= 0 0 set_my_position (final)= 547 413 Window Position Movement (callback):WINDOW_MOVEMENT 1379374 547 414 586 223

My solution: A semaphore. I used these a lot when programming real-time control systems. They work, and are relatively simple to debug. While using a %ud will (eventually) be a more elegant solution, this is serviceable.

The semaphore is initialized (to FALSE) in my generic windows setup routine, set in my %sc routine, and tested in the %mv routine. The %mv will not run unless the semaphore is TRUE. ANY %mv that follows ignores the attempt to call-back. The %sc routine, when it runs, does all the calculations regarding the size/position of the window, and sets the semaphore to TRUE after all that is done. Subsequent %mv's of this (or any other) window will cause the position to be updated globally.

This will work fine for now.

One side effect of this was another learning experience!

If the window to be created is then moved to another display, there is a visible 'blink' as the window is removed from one display and placed on the other display. I thought to make the initial window minimized, but then the size is the size of the taskbar icon, so that does no good. However, making it invisible solved the issue. The size of the resulting window is returned accurately with this technique. The %sc routine moves the window to its new spot, then makes it visible (SET_CONTROL_VISIBILITY@). No blink. Works like a champ.