Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

WindowPad - window-moving tool


  • Please log in to reply
378 replies to this topic
Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Where can I find the current version with the full screen throw capability?

No idea what you're talking about. Are you sure you have the right thread?

Dave Campbell
  • Members
  • 32 posts
  • Last active: May 26 2014 10:07 AM
  • Joined: 09 Jun 2005
I read the entire thread about your Window Pad script and about all of the suggestions. Your original posting was dated 8-2-07 followed by comments that you were incorporating additional features and even stating that the script had a new version number.

What I have since discovered is that its the original posting that has the accumulated changes. Since a lot of the coding is over my head, I didn't read the code itself and missed the fact that the changes were being made to the original posting. It's the posting date of 8-20 that threw me off course and led me to believe it was static and hadn't changed since that date.

I have just finished getting it running and am thrilled with it. My old Nvidia card allowed for throwing to the other monitor, but was incompatible with my upgraded computer. Nvidia no longer supports that feature. Your script fills that gap nicely.

The only feature I would really find useful, even necessary, is the ability to throw maximized screens. I'm using two 21 inch monitors and find it a bit clumsy to have to first restore down, then throw then maximize. Perhaps you could modify the Numpad 5 key to simply throw the screen without any resizing -- at least if the screen is maximized in the first place.

Thank you for a great piece of work!

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

It's the posting date of 8-20 that threw me off course and led me to believe it was static and hadn't changed since that date.

Ah, okay. :) The "last edit date" is at the bottom of the post, in small lettering:

Last edited by lexikos on Fri Aug 17, 2007 11:40 pm; edited 4 times in total

My old Nvidia card allowed for throwing to the other monitor, but was incompatible with my upgraded computer.

When you say "throw", do you mean throw by dragging the window with the mouse, and releasing? I use a script for that in conjunction with WindowPad. There are a number of different versions, but I use a modifier version of foom's ThrowWindows

The only feature I would really find useful, even necessary, is the ability to throw maximized screens.

If by "throw" you mean move with the numpad, it should already work (NumpadDot). Since windows are scaled by the difference in screen working area, maximized windows are automatically resized to fit the working area of the screen they are moved to. However, at least one user found it necessary to restore before and maximize after moving. (I haven't yet added this to the script.)

(The link doesn't always scroll to the right place, :? so look for "MoveWindowToNextScreen".)

Dave Campbell
  • Members
  • 32 posts
  • Last active: May 26 2014 10:07 AM
  • Joined: 09 Jun 2005

It's the posting date of 8-20 that threw me off course and led me to believe it was static and hadn't changed since that date.

Ah, okay. :) The "last edit date" is at the bottom of the post, in small lettering:

Last edited by lexikos on Fri Aug 17, 2007 11:40 pm; edited 4 times in total

My old Nvidia card allowed for throwing to the other monitor, but was incompatible with my upgraded computer.

When you say "throw", do you mean throw by dragging the window with the mouse, and releasing? I use a script for that in conjunction with WindowPad. There are a number of different versions, but I use a modifier version of foom's ThrowWindows

The only feature I would really find useful, even necessary, is the ability to throw maximized screens.

If by "throw" you mean move with the numpad, it should already work (NumpadDot). Since windows are scaled by the difference in screen working area, maximized windows are automatically resized to fit the working area of the screen they are moved to. However, at least one user found it necessary to restore before and maximize after moving. (I haven't yet added this to the script.)

(The link doesn't always scroll to the right place, :? so look for "MoveWindowToNextScreen".)


I saw that last edit date comment but didn't realize the 8-2 posting itself was updated. I kept looking elsewhere. Now I know and that won't happen again.

The word 'throw' was actually an Nvidia term meaning to 'toss' the window from one monitor to the other in exactly the same position without having to drag -- similar to the way your Numpad5 does.

The only remaining problem as I see it, would be to have the ability to switch a maximized window with the ease of using the Numpad5 key used now.

I know you haven't had time yet to address this request, but I was wondering if the Numpad5 function couldn't be modified to switch between the two monitor in a size that fills the screen instead of the centered quarter screen size. That is not a 'maximized' screen but a 'restored' screen that fills the screen. That would result in the 5 key tossing the screen to the other monitor as a centered 'near-full' sized screen instead of the centered quarter screen sized screen.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

The only remaining problem as I see it, would be to have the ability to switch a maximized window with the ease of using the Numpad5 key used now.

Are you aware of the Win+NumpadDot shorcut? It moves the window to the next screen, maintaining relative position and size. As I mentioned earlier, it can move maximized windows.

Perhaps filling the screen would be more useful than sizing to %50, for Win+Numpad5.

Actually, it can be done quite easily. Look for this block of code:
; Determine width/height factors.
    if (dir1 or dir2) { ; to a side
        widthFactor  := dir1 ? 0.5 : 1.0
        heightFactor := dir2 ? 0.5 : 1.0
    } else {            ; to center
        widthFactor  := 0.5
        heightFactor := 0.5
    }
The 'else' block determines the size a window will be set to when you press Win+Numpad5 (the "center" key.) Changing widthFactor and heightFactor to 1.0 would resize the window to fill 100% of the working area of the current screen.

Dave Campbell
  • Members
  • 32 posts
  • Last active: May 26 2014 10:07 AM
  • Joined: 09 Jun 2005

The only remaining problem as I see it, would be to have the ability to switch a maximized window with the ease of using the Numpad5 key used now.

Are you aware of the Win+NumpadDot shorcut? It moves the window to the next screen, maintaining relative position and size. As I mentioned earlier, it can move maximized windows.

Perhaps filling the screen would be more useful than sizing to %50, for Win+Numpad5.

Actually, it can be done quite easily. Look for this block of code:
; Determine width/height factors.
    if (dir1 or dir2) { ; to a side
        widthFactor  := dir1 ? 0.5 : 1.0
        heightFactor := dir2 ? 0.5 : 1.0
    } else {            ; to center
        widthFactor  := 0.5
        heightFactor := 0.5
    }
The 'else' block determines the size a window will be set to when you press Win+Numpad5 (the "center" key.) Changing widthFactor and heightFactor to 1.0 would resize the window to fill 100% of the working area of the current screen.


Yes, I'm aware of the NumpadDot which does move a maximized window to the 'next' screen, but it's out of sight. Hitting it a second time returns it to the original screen. Perhaps that's the underlying problem.

I changed the code as you explained and it works great. The only problem is that although it runs correctly when it's the only ahk running, the change doesn't work when I have my normal ahk running -- not matter what order I load them.

For the time being, I can at least do a double Numpad5 and a Numpad0 to effect the same thing.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Yes, I'm aware of the NumpadDot which does move a maximized window to the 'next' screen, but it's out of sight.

What do you mean by "it's out of sight"? I've never had any problems with it, but as I said earlier, at least one user (apparently) had to make a change for it to work. (Look for "MoveWindowToNextScreen".)

I changed the code as you explained and it works great. The only problem is that although it runs correctly when it's the only ahk running, the change doesn't work when I have my normal ahk running -- not matter what order I load them.

What do you have running in the other script? I usually have at least 3 other scripts running, and it has never given me trouble.

There seem to be a few areas of the script that need work. I'm hoping to get started on v2 today.

Dave Campbell
  • Members
  • 32 posts
  • Last active: May 26 2014 10:07 AM
  • Joined: 09 Jun 2005

Yes, I'm aware of the NumpadDot which does move a maximized window to the 'next' screen, but it's out of sight.

What do you mean by "it's out of sight"? I've never had any problems with it, but as I said earlier, at least one user (apparently) had to make a change for it to work. (Look for "MoveWindowToNextScreen".)

I changed the code as you explained and it works great. The only problem is that although it runs correctly when it's the only ahk running, the change doesn't work when I have my normal ahk running -- not matter what order I load them.

What do you have running in the other script? I usually have at least 3 other scripts running, and it has never given me trouble.

There seem to be a few areas of the script that need work. I'm hoping to get started on v2 today.


It's as if there was a non-existent screen that it's getting shuffled off to with the first NumPadDot but the second NumPadDot brings it back. That problem exists only with a maximized screen.

The NumPad5 key performs properly on a full size (not maximized) window when it's running solo. With my Master.AHK running at the same time, the widthFactor/heightFactor changes don't seem to be effective.

I don't know the difference in terminology between a hotkey shortcut such as #8::run "D:\MyDocuments\Movies Index.xls" and the HotKey command as used in your script. My Master.AHK uses a lot of Windows key shortcuts but does not use the HotKey command.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

It's as if there was a non-existent screen that it's getting shuffled off to with the first NumPadDot but the second NumPadDot brings it back.

That's strange. If you can tell me:[*:1zt7a13c]which version of Windows you are on, and[*:1zt7a13c]the positions and sizes of your monitors,I might be able to reproduce the problem. (If not, fixing it will be more difficult.)

I don't know the difference in terminology between a hotkey shortcut such as #8::run "D:\MyDocuments\Movies Index.xls" and the HotKey command as used in your script. My Master.AHK uses a lot of Windows key shortcuts but does not use the HotKey command.

There isn't much difference. For instance:
Hotkey, #8, RunMoviesIndex, On
;...
return

RunMoviesIndex:
  run "D:\MyDocuments\Movies Index.xls"
return
This is roughly equivalent to
#8::run "D:\MyDocuments\Movies Index.xls"
...but allows the hotkey to be changed more easily (e.g. it could be loaded from an ini file.) I use it mainly to reduce code repitition - i.e. so I don't have to type out 30+ hotkeys.

With my Master.AHK running at the same time, the widthFactor/heightFactor changes don't seem to be effective.

That is very strange. Master.AHK would not include any #Numpad hotkeys (or WindowPad itself), would it? If not, I can't see how #Numpad5 could move the window but not resize it correctly.

Edit: After booting up XP (I was in Vista), I see that moving maximized windows doesn't work right (in XP.) Here's the strange part: moving a maximized window to my secondary screen with NumpadDot put it at:
x-1284 y-4 w1288 h1032
while manually restoring, moving and maximizing the window put it at:
x-1284 y-4 w1288 h1032
As you can see, either way it is in exactly the same place. It seems that somehow the maximized window didn't exist on the secondary monitor, though I could see its right edge on my primary (which is to the right of my secondary.) Perhaps the secondary part of the desktop was covering it up?

In any case, this quick hack (thanks, bobbo and triff) fixes it.

This allows the NumpadDot to work for maximized windows:

MoveWindowToNextScreen:
    gosub WP_SetLastFoundWindowByHotkey
    WinGet, state, MinMax
    if state
	{
        WinRestore
		MoveWindowToNextScreen()
        WinMaximize
	}
    else
		MoveWindowToNextScreen()
return

Similarly, this allows the "Gather Windows" to work with maximized windows (I only the changed last line of the original function, but I'm posting the whole function for completeness):
GatherWindows(md=1)
{
    ;SetWinDelay, -1 ; Makes a BIG difference to perceived performance.
    
    ; List all visible windows.
    WinGet, win, List
    
    ; Copy bounds of all monitors to an array.
    SysGet, mc, MonitorCount
    Loop, %mc%
        SysGet, mon%A_Index%, MonitorWorkArea, %A_Index%
    
    ; Destination monitor
    mdx := mon%md%Left
    mdy := mon%md%Top
    mdw := mon%md%Right - mdx
    mdh := mon%md%Bottom - mdy
    
    Loop, %win%
    {
        ; Set Last Found Window.
        if (!WinExist("ahk_id " . win%A_Index%))
            continue
        
        WinGetPos, x, y, w, h
        
        ; Determine which monitor this window is on.
        xc := x+w/2, yc := y+h/2
        ms := 1
        Loop, %mc%
            if (xc >= mon%A_Index%Left && xc <= mon%A_Index%Right
                && yc >= mon%A_Index%Top && yc <= mon%A_Index%Bottom)
            {
                ms := A_Index
                break
            }
        ; If already on destination monitor, skip this window.
        if (ms = md)
            continue
        
        ; Source monitor
        msx := mon%ms%Left
        msy := mon%ms%Top
        msw := mon%ms%Right - msx
        msh := mon%ms%Bottom - msy
        
        ; If the window is resizable, scale it by the monitors' resolution difference.
        if (IsResizable()) {
            w *= (mdw/msw)
            h *= (mdh/msh)
        }
        
        ; Move window, using resolution difference to scale co-ordinates.
	    WinGet, state, MinMax
	    if state
		{
	        WinRestore
			WinMove,,, mdx + (x-msx)*(mdw/msw), mdy + (y-msy)*(mdh/msh), w, h
	        WinMaximize
		}
	    else
			WinMove,,, mdx + (x-msx)*(mdw/msw), mdy + (y-msy)*(mdh/msh), w, h
    }
}

I'll include this in the next version, assuming I can't find a better workaround. (I'd like maximized windows to move instantly, which they don't do if you restore/maximize.)

Edit: I've applied bobbo's hack to the script in my first post.

Dave Campbell
  • Members
  • 32 posts
  • Last active: May 26 2014 10:07 AM
  • Joined: 09 Jun 2005

It's as if there was a non-existent screen that it's getting shuffled off to with the first NumPadDot but the second NumPadDot brings it back.

That's strange. If you can tell me:[*:2uc9orfe]which version of Windows you are on, and[*:2uc9orfe]the positions and sizes of your monitors,I might be able to reproduce the problem. (If not, fixing it will be more difficult.)

I don't know the difference in terminology between a hotkey shortcut such as #8::run "D:\MyDocuments\Movies Index.xls" and the HotKey command as used in your script. My Master.AHK uses a lot of Windows key shortcuts but does not use the HotKey command.

There isn't much difference. For instance:
Hotkey, #8, RunMoviesIndex, On
;...
return

RunMoviesIndex:
  run "D:\MyDocuments\Movies Index.xls"
return
This is roughly equivalent to
#8::run "D:\MyDocuments\Movies Index.xls"
...but allows the hotkey to be changed more easily (e.g. it could be loaded from an ini file.) I use it mainly to reduce code repitition - i.e. so I don't have to type out 30+ hotkeys.

With my Master.AHK running at the same time, the widthFactor/heightFactor changes don't seem to be effective.

That is very strange. Master.AHK would not include any #Numpad hotkeys (or WindowPad itself), would it? If not, I can't see how #Numpad5 could move the window but not resize it correctly.

Edit: After booting up XP (I was in Vista), I see that moving maximized windows doesn't work right (in XP.) Here's the strange part: moving a maximized window to my secondary screen with NumpadDot put it at:
x-1284 y-4 w1288 h1032
while manually restoring, moving and maximizing the window put it at:
x-1284 y-4 w1288 h1032
As you can see, either way it is in exactly the same place. It seems that somehow the maximized window didn't exist on the secondary monitor, though I could see its right edge on my primary (which is to the right of my secondary.) Perhaps the secondary part of the desktop was covering it up?

In any case, this quick hack (thanks, bobbo and triff) fixes it.

This allows the NumpadDot to work for maximized windows:

MoveWindowToNextScreen:
    gosub WP_SetLastFoundWindowByHotkey
    WinGet, state, MinMax
    if state
	{
        WinRestore
		MoveWindowToNextScreen()
        WinMaximize
	}
    else
		MoveWindowToNextScreen()
return

Similarly, this allows the "Gather Windows" to work with maximized windows (I only the changed last line of the original function, but I'm posting the whole function for completeness):
GatherWindows(md=1)
{
    ;SetWinDelay, -1 ; Makes a BIG difference to perceived performance.
    
    ; List all visible windows.
    WinGet, win, List
    
    ; Copy bounds of all monitors to an array.
    SysGet, mc, MonitorCount
    Loop, %mc%
        SysGet, mon%A_Index%, MonitorWorkArea, %A_Index%
    
    ; Destination monitor
    mdx := mon%md%Left
    mdy := mon%md%Top
    mdw := mon%md%Right - mdx
    mdh := mon%md%Bottom - mdy
    
    Loop, %win%
    {
        ; Set Last Found Window.
        if (!WinExist("ahk_id " . win%A_Index%))
            continue
        
        WinGetPos, x, y, w, h
        
        ; Determine which monitor this window is on.
        xc := x+w/2, yc := y+h/2
        ms := 1
        Loop, %mc%
            if (xc >= mon%A_Index%Left && xc <= mon%A_Index%Right
                && yc >= mon%A_Index%Top && yc <= mon%A_Index%Bottom)
            {
                ms := A_Index
                break
            }
        ; If already on destination monitor, skip this window.
        if (ms = md)
            continue
        
        ; Source monitor
        msx := mon%ms%Left
        msy := mon%ms%Top
        msw := mon%ms%Right - msx
        msh := mon%ms%Bottom - msy
        
        ; If the window is resizable, scale it by the monitors' resolution difference.
        if (IsResizable()) {
            w *= (mdw/msw)
            h *= (mdh/msh)
        }
        
        ; Move window, using resolution difference to scale co-ordinates.
	    WinGet, state, MinMax
	    if state
		{
	        WinRestore
			WinMove,,, mdx + (x-msx)*(mdw/msw), mdy + (y-msy)*(mdh/msh), w, h
	        WinMaximize
		}
	    else
			WinMove,,, mdx + (x-msx)*(mdw/msw), mdy + (y-msy)*(mdh/msh), w, h
    }
}

I'll include this in the next version, assuming I can't find a better workaround. (I'd like maximized windows to move instantly, which they don't do if you restore/maximize.)

Edit: I've applied bobbo's hack to the script in my first post.


1) I'm running a Dell desktop with two Samsung 21 inch monitors on Windows XP Pro SP2. One monitor, a 213T is used as digital on the left and a 214T as analog on the right. They're both being used from an Nvidia GeForce 7300 LE.

2) Is there any advantage of the Hotkey command over the other method? Any particular reason why you use it extensively in WindowPad in instead of the other?

3) I had to comment out all of my NumPad commands in Master AHK when I started loading WindowPad because of the conflict. I just checked and the only uncommented use of such keys is in WindowPad which I've not altered except for the NumPad5 key screen size. But, this seems to be a non issue now because of bobo's fix.

4) Your description of barely seeing the right edge describes exactly what I'm seeing.

5) Gangbusters! bobo's code works. Now I can really brag about WindowPad. I don't use the gather function and haven't experienced the problem yet but will play with it later.

6) Unless I'm missing something, it looks like there's no problem with moving maximized windows instantly.

Hey, thanks for working with me on this. It makes my day to see a lot of effort pan out and become productive.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Unless I'm missing something, it looks like there's no problem with moving maximized windows instantly.

Not really a problem, just me being nitpicky. I can see the intermediate moves (maximized -> restored, move, restored -> maximized), and that bothers me. More importantly, it seems the WinRestore,WinMaximize hack has another negative side-effect (at least on Vista): after moving a maximized window from one screen to the other, if I restore the window... it extends outwards. That is, it ends up larger than the screen.
(Edit: Disregard that - I was erroneously using the window's maximized size in calculations.)

I think the solution may be SetWindowPlacement:

The SetWindowPlacement function sets the show state and the restored, minimized, and maximized positions of the specified window.

It might even be possible to move maximized windows without restoring them first.


Progress report: ;)

The "hotkey customization system" is virtually complete. The implementation is so abstract that the hotkey initialization can be done in one line:
Hotkey_Params(WindowPad_INI_GetList(ininame, "Hotkeys", "Hotkey"))
WindowPad_INI_GetList() gets a list of "Hotkey" values from the "Hotkeys" section of the ini file. Examples:
[Hotkeys]
Hotkey=  #Numpad1:: WindowPadMove, -1, +1,  0.5, 0.5
Hotkey=  #Numpad2:: WindowPadMove,  0, +1,  1.0, 0.5
Hotkey=  #Numpad3:: WindowPadMove, +1, +1,  0.5, 0.5
...
Hotkey= #NumpadDiv:: GatherWindows, 2
Hotkey= #NumpadMult:: GatherWindows, 1
(All of the hotkeys are customizable this way.)

Hotkey_Params() then maps the hotkeys to their associated "commands." Commands are implemented as labels, with the parameter list stored in Params, and parsed as needed by the "command." Commands can be added arbitrarily, and hotkeys can be added to move a window ("A", "P" (WinPreviouslyActive()) or by title) in one of nine directions (counting "center" as a direction) and sizing to any factor of the screen size (0.0 - 1.0; values > 1.0 will be interpreted as absolute sizes.)

In hindsight, all that would've already been possible by editing the script itself,
#Left::MoveWindowInDirection(-1, 0, 0.5, 1.0)
however, that wouldn't allow customization after the script is compiled. Storing the settings in an .ini file would also allow per-user configurations, though I haven't implemented that.


Next comes the GUI for configuration, possibly* in the form of a "wizard" - set your main "pad" keys, prefix keys (for the active window or the window beneath it), and utility keys (maximize, move to next screen, etc.) Advanced configuration (additional hotkeys) will probably be left in the form of a text editor.

* feedback welcome.

I also plan to eventually implement JOnGliko's double-click idea, a minimize hotkey of some form, and co-operative resize (my name for ezuk's idea.)

Is there any advantage of the Hotkey command over the other method? Any particular reason why you use it extensively in WindowPad in instead of the other?

Yes - it is the only way to allow hotkeys to be customized without editing the script itself.

It makes my day to see a lot of effort pan out and become productive.

Couldn't have said it better myself. :)

I think if you add some nice tray icons, add a simple GUI for configuration, and upload an exe for non-AHK users, this utility will blow these closed-source alternatives out of the water.

Lastly, if anyone has ideas for a tray icon, let's hear/see them. :)

TMLGuy
  • Guests
  • Last active:
  • Joined: --
This is a great app! Made my life with multiple monitors so much easier.

My apologies as I am new here... I have noticed that when I use the combination to paste: "SHIFT-INSERT" this code is preventing me from using it. Is that normal with AutoHotkey? As soon as I stop the program it allows me to use it again. I can use "CTRL - V" with no issues while the code is working.

I am using Win2k not sure if its a compatibility issue? Did I do something wrong?

Thanks in advance for your help.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Thanks for the bug report. I had noticed the issue after assigning "AppsKey & ..." in the current beta, but since that part of the script is entirely different, I hadn't thought to update the current released version. I've updated the script in my first post.

The issue was that "Insert & Numpad1" etc. causes Insert to lose its native function. To give it back its native function, I had used an "Insert" hotkey and "Send {Insert}" (Insert=%EasyKey%), but this doesn't work with Shift+Insert. The fixed code reads:
Hotkey, [color=green]*[/color]%EasyKey%, SendEasyKey ; let EasyKey's original function work (on release)
;...
SendEasyKey:
    Send [color=green]{Blind}[/color]{%EasyKey%}
    return
'*' lets the hotkey trigger when any modifier keys are pressed, and {Blind} tells it not to automatically release any modifiers for the Send.

TML guy
  • Guests
  • Last active:
  • Joined: --
I appreciate the quick response! Worked like a charm :D

ezuk
  • Members
  • 149 posts
  • Last active: Jan 02 2013 08:54 AM
  • Joined: 04 Jun 2005
Hi Lexikos!

I have another feature request, tell me what you think:

Currently, if a window takes up the entire right side of the screen and I hit Win+Numpad 6 again, it jumps to the next monitor. That's great!

However, if a window takes up the lower-right side of the screen (bottom quarter) and I have Win+Numpad 3 again, nothing happens. I want to use this to squeeze in another feature: In this state, hitting Win+Numpad3 would reduce the size of the window by half, horizontally. It would make it as wide as 1/8 of the monitor, and stick it to the right-side of the square. But if that side is already occupied by a window, it would stick it in the left-side of the square.

This way, I could have two 1/8th-sized tiny windows in one 1/4 of the screen.

This is useful for many applications which don't take up much space but I still want to see, such as Foobar2000, ToDoList, and Miranda IM.

What do you think?