I've got a two-screen setup for my main pc A, with a second pc B sometimes using screen 1 so that for my main pc A screen 2 only is available (both pc's being connected to screen 1, with manual input switch on the screen).
I've got some "standard" distribution of the windows of my applications between screens 1 and 2, in my pc A setup, and whenever then screen 1 only is available, I obviously will have to move the application windows which "normally" are displayed on screen 1, to screen 2, too, and that also applies to my AHK inputboxes, etc. - if I do nothing about this, all these are "displayed" and "active" on screen 1, i.e. pressing "return", etc. will work as expected, even those dialogs not being visible.
It's obvious that first, I will have to adjust the positions of my dialogs in function of their "parent" windows, i.e. their position will henceforward be determined by the position of the applications to which they apply, and which would be to be retrieved first then; this is just lots of coding work but does not present any technical difficulty.
On the other hand, I currently miss a "direct" way to check for the presence or absence of screen 1, in order to properly display the application windows (which ordinarily are displayed on screen 1 if just pc A is using my screens), onto screen 2 (when both pc's A and B are "on"); of course, I could realize this by a global variable which would be checked every time my script positions a window, e.g. global sysscreencount = 1 or 2 (with default being 2), by some key combination like shift-control-alt-F12 or similar, but I'm looking for some "automated" way of setting such a variable respectively "telling" my script what the current state of screen availability is.
Any suggestions?
(Changed title)
Can AHK determine if a screen - connected to 2 computers concurrently - is or is not available?
Can AHK determine if a screen - connected to 2 computers concurrently - is or is not available?
Last edited by rhl on 07 Jan 2021, 14:55, edited 1 time in total.
Re: Is there a direct way AHK checks for some screen to be available?
Hi
you can check that with
a) A_ScreenWidth
and with
b) SysGet, VirtualWidth, 78
a) delivers the with of the first/primary screen/monitor and b) delivers width of both (or more) screens/monitors together.
Therewidth you are able to check wether your are in front of a one- or a more-monitor-System
JB
you can check that with
a) A_ScreenWidth
and with
b) SysGet, VirtualWidth, 78
a) delivers the with of the first/primary screen/monitor and b) delivers width of both (or more) screens/monitors together.
Therewidth you are able to check wether your are in front of a one- or a more-monitor-System
JB
AHK: 1.1.37.01 Ansi, 32-Bit; Win10 22H2 64 bit, german
Re: Is there a direct way AHK checks for some screen to be available?
Jovannb, thank you very much for your hint. Unfortunately, this does not work.
I have got two HP screens, 1= 1920x1200 and 2= 2560x1440, left to right on my main pc system A; both are connected by HDMI.
Screen 1 is also connected, by DisplayPort, to system B.
Then, when both systems are connected, and both screens are "on", I can, on screen 1 (the left one), switch that screen 1 from HDMI to DisplayPort and vice versa, either going by a screen menu or by a "quick switch" button on the screen which I have to tap twice (toggle between HDMI and DisplayPort).
Now, when screen 1 is set to system B, and should not be available to system A, and I do, in system A
(both systems have their own keyboard and mouse, the idea being to shield system B from the web, which would not be the case if I used some electronic KVM which would give access to system B, from system A, and thus would give access to system B, from any virus or other web actor having access to system A),
I do NOT see the MsgBox, and if I then switch screen 1 to system A, the MsgBox will be visible on screen, with the value "1920" which obviously is the screen width of screen 1 which, at the time I had triggered the scriptlet, had shown the desktop of system B.
In other words, my HP screen 1 screen-switch obviously does NOT "inform" the system A that screen 1 is currently not available anymore to system A, but system A "thinks" it always disposes of a "big screen", i.e. the combination of screen 1 and screen 2, and accordingly "displays" messages, physically invisible now, on screen 1; ditto (I didn't try but I'm sure) for the "overall" screen width, i.e. the addition of the widths of screen 1 and 2.
Currently, I only can imagine checking the color of some screen pixel on screen 1, which could be different between (screen 1 really visible and usable in/to system A) and (screen 1 currently used by system B), since (not tried but I'm sure) system A will even tell me "window xy is visible on screen 1" when in fact it is not, screen 1 currently being switched to system B, but I obviously am looking for some more "elegant" solution; other screens than my HP one will probably present the similar problems in my current setup, so this may be of more general interest.
I also tried the following:
(I know how I would shift the MsgBox, see the scriptlet by Odlanir in https://www.autohotkey.com/boards/viewtopic.php?t=47650 )
And, as expected, unfortunately, I do NOT get any negative* "x" value for that window, but I get the same value as if both screens were really available for system A.
*=The value I'd get if all went right, SHOULD be negative indeed, since the only really available screen 2 would "start" at 0, and the app window on the not-available screen 1 is on the LEFT on the only available screen. Instead, I get a positive value, counting from position 0 of the now not-available screen 1.
It's obvious then that either my system A (1) or then, AHK (2), "thinks" the whole surface of screens 1 and 2 is available, when in fact screen 1 is used by system B and only displays what system B tells the screen to display.
It's evident that, if the problem is (A), nothing can be done about it, from the AHK development side, but if the problem is (2), AHK could be amended in order to "get it right"?
*=I often run the same applications on both systems, concurrently, so asking for the name of the current window would not identify the screen setting; I could try to fetch the unique identifiers, but that would not help any further, since there is - on purpose, as stated above - no data communication between systems A and B.
For the time being, I probably should implement a "manual" switch, i.e. "tell" my system A, by some toggle, whenever it's not in its default state (which is "both screens are available").
I have got two HP screens, 1= 1920x1200 and 2= 2560x1440, left to right on my main pc system A; both are connected by HDMI.
Screen 1 is also connected, by DisplayPort, to system B.
Then, when both systems are connected, and both screens are "on", I can, on screen 1 (the left one), switch that screen 1 from HDMI to DisplayPort and vice versa, either going by a screen menu or by a "quick switch" button on the screen which I have to tap twice (toggle between HDMI and DisplayPort).
Now, when screen 1 is set to system B, and should not be available to system A, and I do, in system A
(both systems have their own keyboard and mouse, the idea being to shield system B from the web, which would not be the case if I used some electronic KVM which would give access to system B, from system A, and thus would give access to system B, from any virus or other web actor having access to system A),
Code: Select all
MsgBox, %a_screenwidth%In other words, my HP screen 1 screen-switch obviously does NOT "inform" the system A that screen 1 is currently not available anymore to system A, but system A "thinks" it always disposes of a "big screen", i.e. the combination of screen 1 and screen 2, and accordingly "displays" messages, physically invisible now, on screen 1; ditto (I didn't try but I'm sure) for the "overall" screen width, i.e. the addition of the widths of screen 1 and 2.
Currently, I only can imagine checking the color of some screen pixel on screen 1, which could be different between (screen 1 really visible and usable in/to system A) and (screen 1 currently used by system B), since (not tried but I'm sure) system A will even tell me "window xy is visible on screen 1" when in fact it is not, screen 1 currently being switched to system B, but I obviously am looking for some more "elegant" solution; other screens than my HP one will probably present the similar problems in my current setup, so this may be of more general interest.
I also tried the following:
Code: Select all
WinGetPos, x, y,,, SomeAppWindow
; msgbox, %x%`n%y% ; not visible, as explained
clipboard := x . " " . y ; I can then retrieve the clip-content in some
; editor displayed on screen 2, without having to switch back and forth
; to screen 1 again, in order to just read the MsgBox message
And, as expected, unfortunately, I do NOT get any negative* "x" value for that window, but I get the same value as if both screens were really available for system A.
*=The value I'd get if all went right, SHOULD be negative indeed, since the only really available screen 2 would "start" at 0, and the app window on the not-available screen 1 is on the LEFT on the only available screen. Instead, I get a positive value, counting from position 0 of the now not-available screen 1.
It's obvious then that either my system A (1) or then, AHK (2), "thinks" the whole surface of screens 1 and 2 is available, when in fact screen 1 is used by system B and only displays what system B tells the screen to display.
It's evident that, if the problem is (A), nothing can be done about it, from the AHK development side, but if the problem is (2), AHK could be amended in order to "get it right"?
*=I often run the same applications on both systems, concurrently, so asking for the name of the current window would not identify the screen setting; I could try to fetch the unique identifiers, but that would not help any further, since there is - on purpose, as stated above - no data communication between systems A and B.
For the time being, I probably should implement a "manual" switch, i.e. "tell" my system A, by some toggle, whenever it's not in its default state (which is "both screens are available").