Sublime Forum

Workaround for windows rendered off screen

#1

For those people who are using Windows and having the issue where if you pull a tab from a window and drop it on a different monitor and your window gets rendered off screen, I have a solution that will make things feel a bit more normal. (This issue has been reported by a number of people).

I think it is a shame that I have to do this for a stable release version of ST2 (that I have paid for), but alas it appears this issue is getting no love.

Below is a AutoHotkey script that will look for when ST2 windows are created, if their Y coordinates are off the screen, it should move the window vertically under the mouse. This will make ST2 appear to work how it should be working.
[pre=#000000]#Persistent
SetBatchLines, -1
Process, Priority, High

Gui +LastFound
hWnd := WinExist()

DllCall( “RegisterShellHookWindow”, UInt,hWnd )
MsgNum := DllCall( “RegisterWindowMessage”, Str,“SHELLHOOK” )
OnMessage( MsgNum, “ShellMessage” )
Return

ShellMessage( wParam,lParam ) {
If ( wParam = 1 ) ; HSHELL_WINDOWCREATED := 1
{
WinGetTitle, Title, ahk_id %lParam%
If ( RegExMatch(Title, “- Sublime Text 2$” ))
{
WinGetPos, Xpos, Ypos, , , ahk_id %lParam%
if ( Ypos > A_ScreenHeight || Ypos < 0) {
CoordMode, Mouse, Screen
MouseGetPos, Xmouse, Ymouse
WinMove, ahk_id %lParam%, Xpos, Ymouse
}
}
}
}[/pre]

Hope this helps some people. Hopefully this issue will be fixed in the near future and allow us to get rid of such a script. This is why I am not creating a repo for such a script; I am optimistic that this issue will be resolved in ST2 sometime soon.

0 Likes

#2

I was having this problem with WinXP every single time. I moved to Win7 sometime ago, and I’ve never seen the problem again, I can’t reproduce it.

0 Likes

#3

I am on Win7 64bit, and I can reproduce it all of the time. This inconsistency across like machines is unfortunately why Jon cannot reproduce it. I have had this issue on an old XP computer, an older Win7, and now this brand new Win7 at work. More than likely there is an issue with the method by which the screen size/position is determined. Based on possibly certain graphics HW? maybe things get returned funny on some systems. It is difficult to guess because I have no idea what method Jon uses to position the windows, but the problem is very real on modern systems.

0 Likes

#4

My workaround has simply been to create a new window first (Ctrl+Shift+N) and drop the tabs on that. Anyway, this is a great looking script and I will try it out, just to play with and learn more about AHK.

@tito: it only seems to happen on multi-monitor systems at the moment.

0 Likes

#5

I used to do that too. I figured there had to be a better way though. I am always amazed at what you can do with AutoHotKey; I don’t use it nearly as much as I should, but when I do, I always wonder why I don’t use it more.

0 Likes

#6

[quote]@tito: it only seems to happen on multi-monitor systems at the moment.
[/quote]

It was happening to me on a single monitor notebook.

I use multimonitor with ultramon installed now.

0 Likes

#7

Hmm, now it’s happening on my single-monitor Windows Vista machine at home, when I know it was working correctly here yesterday.

Actually it’s very erratic. The X position is always consistent with where I drop, but the Y position is not. Sometimes the window is opening where I drop it vertically, like on the very top of the screen. Other times it draws part way down the screen, even if I drop it at the top. It’s a mystery.

0 Likes

#8

Happens to me on Win7 64bit. I have a dual screen layout, it also affects my open/save dialogs as well.

0 Likes

#9

I suspect that there are a number of people who have seen/experience this issue, but have dealt with it because it can be sporadic; I know I did for a while. I think it is good people are chiming in expressing that they have seen this issue. I think it will help in giving this issue some priority.

0 Likes