Question about "the screen" property of stacks...
paul at researchware.com
Thu Jul 11 13:26:23 EDT 2019
Thank you Mark!
I will create an abbreviated summary for the Dictionary entry.
I can now see why the programmer will get a screen number for the stack
even if the stack is not "on" any actually monitor (use loc to screenLoc
line calculation), which is actually very helpful. Our application has a
preferences that allows the user to save their window placement between
sessions and we have to address the issue that a window may have been on
a monitor that is no longer present the next time our app starts up
We'd thought about just resetting the window to its default position,
but seeing this, it makes more sense to me to move the window to the
screen with the closest center.
On 7/11/2019 1:08 PM, Mark Waddingham via use-livecode wrote:
> On 2019-07-11 17:17, Paul Dupuis via use-livecode wrote:
>> The screen of stack X returns the number of the monitor (the line
>> number for the screenRects) that the stack/window is on.
>> If someone from the mothership can verify, I would be happy to open a
>> doc bug, update the dictionary, and generate a PR for an update to the
>> screen property Dictionary entry to clarify these two points.
> The engine compares the content rect (not effective!) of the stack to the
> working area of each screen and takes the screen with which it shares the
> most area (the intersection of the stack's rect and the working area rect
> of the screen is a rectangle - and its the area of that which is used).
> If the stack's rect has no intersection with any screen working area then
> it uses the screen which has the closest center point to the window's
> point (by calculating the length of the line between the two points).
> Ties are by display index - the primary display is always first, the rest
> are in order as given by the OS to LC.
> To be completely unambiguous - here is the routine the engine uses (in
> case asked, the p_rectangle would be the rect of the stack being
> const MCDisplay *MCUIDC::getnearestdisplay(const MCRectangle&
> MCDisplay const *t_displays;
> uint4 t_display_count;
> uint4 t_home;
> uint4 t_max_area, t_max_distance;
> uint4 t_max_area_index, t_max_distance_index;
> t_display_count = MCscreen -> getdisplays(t_displays, false);
> t_max_area = 0;
> t_max_distance = MAXUINT4;
> t_max_distance_index = 0;
> for(uint4 t_display = 0; t_display < t_display_count; ++t_display)
> MCRectangle t_workarea;
> t_workarea = t_displays[t_display] . workarea;
> MCRectangle t_intersection;
> uint4 t_area, t_distance;
> t_intersection = MCU_intersect_rect(p_rectangle, t_workarea);
> t_area = t_intersection . width * t_intersection . height;
> uint4 t_dx, t_dy;
> t_dx = (t_workarea . x + t_workarea . width / 2) -
> (p_rectangle . x + p_rectangle . width / 2);
> t_dy = (t_workarea . y + t_workarea . height / 2) -
> (p_rectangle . y + p_rectangle . height / 2);
> t_distance = t_dx * t_dx + t_dy * t_dy;
> if (t_area > t_max_area)
> t_max_area = t_area;
> t_max_area_index = t_display;
> if (t_distance < t_max_distance)
> t_max_distance = t_distance;
> t_max_distance_index = t_display;
> if (t_max_area == 0)
> t_home = t_max_distance_index;
> t_home = t_max_area_index;
> return &t_displays[t_home];
> [ And yes - I just noticed that 't_max_distance' is a misnomer - it
> should really be
> t_min_distance! ]
> Hope this helps!
> Warmest Regards,
> P.S. The reason it works without a stack being open is because it is
> an entirely
> 'logical' operation based on the rect of the stack not effective rect.
More information about the Use-livecode