I just recently started working with multiple monitors (3 with one being a TV!), so I never had the ramifications of coding for that situation.
Xojo provides the Screen function with lets us get the available dimensions for any screen connected… But how do you determine which screen a window is on?
I looks like You can’t just use the top,Left properties of a window as, at least on the Mac in 10.9, the window can actually be displayed on an adjacent screen and the part on the calculated screen be invisible!
[code] dim winScreen as screen = nil
dim u as integer = ScreenCount-1
for i as integer = 0 to u
dim s as screen = screen(i)
dim x as integer = win.Left + win.Width / 2
dim y as integer = win.top + win.Height / 2
if x >= s.Left and y >= s.top and x <= s.left + s.Width and y <= s.top + s.Height then
winScreen = s
end if
next
I can’t look up the code now, but this problem was solved on the mailing list The code used whichever screen had the greatest percentage of the window. I think I posted that code to the forums at some point too.
What seems to matter on the Mac is what screen the cursor was on when you dropped the Window when dragging by the title bar. Because of that, any percentage could be on either screen!!!
This looks like it would require a declare and then having to figure out how much of the window is actually being displayed…
BTW I tried setting two of the monitors to the same resolution to see if the Window would then span them … it does not.
So that is on the Mac…
What happens on Windows if a window spans screens? Is it different if the Screens have the same dimensions or if they are different!
Trying to deal with multiple monitors in code is a pain!!!
BTW in the IDE the Autocomplete menu can be made to popup on other screen where the rest of the Window would be if it was visible there… Strange looking but maybe that is teh simplest things to do!
Here is What I mean. the IDE is actually on the screen to the left. the picture
[quote=155035:@Kem Tekinay]I can’t look up the code now, but this problem was solved on the mailing list The code used whichever screen had the greatest percentage of the window. I think I posted that code to the forums at some point too.
If you can’t find it, I’ll post when I can.,[/quote]
Thank Kem ,
But don’t bother … What I’m doing is implementing a hierarchical pallet… and what I need to know where to popup the sub pallets. I’ll just handle it the way the IDE does autocomplete.
In any case, as I said at least on the Mac the percentage on screen is not the determining factor on which screen the Window is displayed.
Part of the window will be drawn on one screen and part on the other. It will be possible to click in either screen, but the coordinates of the click will still tell you which one. Besides, if you use the click coordinates to place the popup, you don’t need to know which screen it is at all.
Actually if possible i want the child pallet in a specific place relative to the parent pallet, and not depend on teh exactly where the click was. I am bit of stickler for things like that
[quote=155134:@Karen Atkocius]Hi Sam,
I need this to be Xplatform so am trying to avoid declares.
Karen[/quote]
Gotchya,
I wonder… the realbasic.rect has intersecting functions, the window has a bounds property which returns a said rectangle. So in theory you should be able to grab the rect of the window, and then build rects from the screen() and using the intersecting function determine on which screen the window is better intersecting???
[quote=155291:@Sam Rowlands]I wonder… the realbasic.rect has intersecting functions, the window has a bounds property which returns a said rectangle. So in theory you should be able to grab the rect of the window, and then build rects from the screen() and using the intersecting function determine on which screen the window is better intersecting???
[/quote]
Actually I solved the issue another way…
but No what you suggest would not work on a Mac at least. As i mentioned above , when Window spans monitors the monitor it is displayed does NOT depend which monitor which monitor have more of the area as one might expect.
What determines it when you are dragging a window by the title bar is where teh mouse cursor is when you “drop” it!!! That means the Window could only be visible on the monitor where only a small percentage shows.
An interesting use of this could be to store a window’s position:
get the screen the window is on
get that screen’s dimensions
get the relative position on that screen in a factor format
store the screen id (number or something like that)
store the factorized position and dimension
The factorized values are like:
0.0 = left
0.5 = center
1.0 = right
Same as for vertical values.
It’s easily calculated back. Where the value is just multiplied by the maximum value.
I do this all the time when certain sizes are somehow dynamic.
I have a subtitle app. And instead of using fixed pixel-based sizes I use the factor of the height of the screen. My default font size is 0.2
Works great in case I need to have a scaled representation of my titles.
And this works too with windows that might appear on different screen sizes. One might change a screen (projector, 4k monitor, etc). It really doesn’t matter. The windows will just adapt to the screen size they live on.