forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Multiple displays and saving/using coordinates

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 653
Location: Morrison, CO, USA

PostPosted: Mon Oct 14, 2019 3:07 am    Post subject: Multiple displays and saving/using coordinates Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6067
Location: Salford, UK

PostPosted: Mon Oct 14, 2019 7:01 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6067
Location: Salford, UK

PostPosted: Mon Oct 14, 2019 9:36 am    Post subject: Reply with quote

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."
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 653
Location: Morrison, CO, USA

PostPosted: Mon Oct 14, 2019 1:16 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 653
Location: Morrison, CO, USA

PostPosted: Mon Oct 14, 2019 10:51 pm    Post subject: Reply with quote

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 RED.

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 Last movement of first window
**** Unrecognized KEY PRESSED=535 (Z:217) This starts the second window on Display 2
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 Start of %mv for second window
set_my_position (current)= 1313838 WINDOW_STARTUP 0 Start of %sc for second window]
set_my_position (current)= 224 73 1232 905
set_my_position (before)= -1680 0
set_my_position (final)= -1456 72 End of %sc for second window
Window Position Movement (callback):WINDOW_MOVEMENT 1313838 224 73 1232 905 End of %mv for second window
Now, the third window gets created, but in display 1 because of the ending of the %mv above
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
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 653
Location: Morrison, CO, USA

PostPosted: Tue Oct 15, 2019 2:31 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group