AutoHotkey Community

Windows won't let you put a (virtual) gap between two monitors.
Yes, but not perfectly.

GDI could be used to print the window's contents onto some other window. This has problems, especially with games, but works for many applications.

When desktop composition (i.e. "Aero") is enabled in Windows Vista, you can create a full-sized "thumbnail" which perfectly reflects all or part of a window. I've used this method to create an interactive mini-copy of a window.

The real problem is properly forwarding mouse and keyboard events (especially mouse) to the target window. I tried with ControlClick, but the results were very inconsistent - some controls seemed to get the click at an offset, others seemed to work fine.

I've hesitated to write this since I'm such a huge fan of this script. With a wide-screen laptop and a 24" monitor being used together, then separately, as I undock for meetings then dock back in my office, I'm gathering/shifting/resizing windows constantly. Thank you again, lexicos, for the work on this.

I use both numpad controls when docked (separate keyboard) and the Capslock control when undocked (notebook keyboard only). Another great feature that you support the no-numpad use case.

Now to my small issue. Let's say I use Capslock just to switch to all caps to type, oh, DES (data encryption standard). What often happens is the time between pressing Capslock and pressing D isn't long enough and WindowPad picks it up as a Capslock-D and shifts the window to the right.

Is there a way to set the "sensitivity" on the Capslock key, so (for example) Capslock must be held down for a period of time (250ms?) before activating the "window move" hotkey combination? Maybe the capslock+modifier must be held down for a certain period of time before it captures the key as a shortcut?

I looked briefly through the code, and unfortunately with my rudimentary skills wasn't able to find a way to insert logic of this type.

LexiKos, any thoughts on an approach? I've dealt with this since first installing WindowPad so it's not a huge deal, but an irritant I hit a few times a day.

I've encountered this sort of problem with hotkeys in the past, so it was an easy fix.

WindowPad v1.51:

• Use WindowPad_Init(IniPath) to initialize WindowPad if it is #included in another script. IniPath may be omitted. Gosub WindowPadInit will also work as before.
• Added D option to the Hotkeys command. For example, the following will use CapsLock as a hotkey only if it is held for 0.1 of a second.
  
  Code:
  CapsLock = Hotkeys, Active Window (WADS), D0.1
  
  Currently only "visible" keys (caught by the Input command) are checked. If D is specified without a number, the default delay is 0.1.
• Added commands: Minimize, Unminimize, Restore. Minimize and Restore accept a window parameter (standard WinTitle, P or M; defaults to A if omitted.) Unminimize works only with the top-most minimized window in the z order.

Sweet. Works like a charm. Thanks.

In case someone else is interested, I thought it was worth mentioning a couple of .ini tweaks that work for me:

• Implemented the new D option. D0.1 works well so far.
• I set CapsLock+s to be MaximizeToggle. This works a bit better for me since the default behavior maximizes (first press) and then swaps screens (second press). MaximizeToggle matches my expectation a bit more. If I want to swap, I just use the default CapsLock+Space key.
• I took advantage of the new option and set CapsLock+Esc to Minimize the active window. Since the next windows in the Z order gets activated, I can quickly minimize many windows sequentially. Very convenient when I have a lot of emails open and need to get them out of the way.

For reference, the top section of the WindowPad.ini is now:

A quick question: I notice that the Numpad hotkeys now have an asterisk in front of them. This looks like a change since 1.50, but I don't see a difference in behavior. Any reason for this?

The default ini is slightly different from what I use personally:

• Capslock+s sets 50% width rather than 100%, since 50% is typically more comfortable on my 22" widescreen.
• Capslock+f sets 100% width and height, for the rare occasions when I want a window to fill the screen but not maximize.
• I recently replaced the default Numpad layout (which I never used) with a layout that toggles with Numlock. NumpadHome, etc. are normally useless to me given that they're right next to regular Home, etc. which are laid out more intuitively on my keyboard. With the new layout, I can move windows around (and minimize, maximize, etc.) using only the numpad while numlock is off. (I have WindowPad embedded in my hotkey script, which sets Numlock to ON initially.)

The modified numpad layout:
I agree that the current behaviour of switching screens when the window is already in its target position isn't overly useful. I would like to eventually introduce an "alternation" or "command separator" construct. For instance, the current behaviour could be expressed as:
It could easily be changed to cycle between two configurations:
MaximizeToggle could be expressed as:
I'm still toying with command / parameter-passing styles, but the above seems more readable and more immediately obvious than the current style. It could even be implemented as an actual AutoHotkey expression...

More importantly, I plan to eventually separate definition of the "pad" keys, "prefix" keys and pad layouts. This will make it much easier to configure, and much easier to write a functional GUI for configuration.
The default "prefix keys" don't need the asterisk, but including it makes it easier to edit the configuration to use ^ ! or #. + still can't be used, since it activates some low-level Windows feature that virtually "disables numlock."

Hi,

WindowPad is the best solution I have found for managing windows using single and dual monitors. I stopped using UltraMon because I prefer WindowPad . I have one feature request:

Allow disabling WindowPad for certain processes and/or windows.

A configuration option similar to the Gather Exclusion would be nice.

My biggest reason for this is RDP, VNC and virtual machines. I often connect to machines using remote desktop, and I often run virtual machines. I install windowpad on ALL machines i use - including virtual ones.

By disabling WindowPad for these applications, I can use the WindowPad instance on the remote/virtual machine.

Anyway, WindowPad is one of my favorite AHK scripts. Great work!

Mario Pareja

I've added an [Exclude Windows] feature. Unfortunately, autohotkey.net seems to be having problems. I've uploaded the new version, but for the moment you'll probably get "Internal Server Error" if you try to download it.

In the interim, you may add something like the following to the top of Hotkey_Params():
You may also need this in the auto-execute section:

Edit: The issue with autohotkey.net has been resolved, so the latest version of WindowPad (see my original post) may now be downloaded.

Wow!

Lexikos, I can't believe you implemented that feature so quickly! Great work. Once again, I must say WindowPad is one of my favorite utilities on my machine and every machine I ever have the pleasure of sticking my USB key into.

Thanks,

Mario

Props to Lexikos - awesome work!

I decided to try WindowPad out before posting in this thread, and I've been using it on and off for a few weeks now. It does seem to work very well - it's very customizable and performs all it's tasks well on the various dual-monitor configurations that I have.

I did find one issue, which involves how WindowPad moves windows after consecutive identical commands. I briefly tried reading through the script, but I didn't find anything worth reporting.

When pressing the same shortcut more than once, WindowPad sometimes continues to move the window in that direction. For example, let's say a window starts aligned right-most. When you issue 'align left-half' (NumPad0 + 4 using my configuration, 'WindowPadMove, -1, 0, 0.5, 1.0' in the code), the window moves to the left-half of that same monitor. If you have a monitor to the left, then pressing the shortcut again will move the window in the right-half of that left-monitor. Pressing it yet again will move it to the left-half of that left-monitor. This is great, I love it!

However, this is not consistent with the 'corner' moves. If a window is in the bottom-right corner of the right-monitor and you issue a 'left-corner' command, the window moves to the left-corner of the right-monitor. If you issue the same command again, nothing happens. While this is different than the behavior of the 'half-screen' commands, it's still fine - I can use the half-screen moves to change monitors, and then use the corner command to move to the proper corner.

The bug that I think I am seeing is that one of the corner move commands does keep moving the window across the monitors. All my corner-move commands simply move the window into the specified corner of the current monitor, except the lower-right corner command when run on a window on the left-monitor . The first press moves the window into the lower-right corner of the left-monitor, the second moves the window into the upper-left of the right-monitor (!!!), and the third moves the window into the lower-right of the second monitor.

Ideas? I will try to find other dual-monitor machines with different configurations to test how this behaves, but the issue may be due to my non-standard dual-monitor configuration, which is [L_R] = [1280x1024_1024x1280]. This is when using WindowPad v1.52 with my other AHK scripts closed.

_________________
-Thracx

"Man wants to know, and when he ceases to do so, he is no longer a man."
-Fridtjof Nansen

WindowPadMove works by finding the monitor one pixel beyond the relevant edge or edges. If there is no monitor in that direction, it does nothing. In your case, the right monitor is down and to the right of the left monitor, but the left monitor is not down and to the left of the right monitor.
A move downward puts the window on the top of the destination screen, and a move to the right puts the window on the left side. It stands to reason that a move down and right puts the window in the top-left of the destination screen.

See page 4 for another visualization.

Ahh, now it all makes a lot more sense, thanks Lexikos!

I've made some minor modifications to my copy of WindowPad to 'fix' my issue, which may or may not be useful to others. For anyone who experiences problems like mine, I'm posted the extra code that I wrote to fix it. Maybe Lexikos will integrate something like this into his source if it ends up being useful, but since there's little need for that users with the issue can just edit their copies per below.

Note: Remember that my issue is because my monitors, as a whole, do not form a proper rectangle. Nearly all people have monitor configurations which do form a proper rectangle, so this is not an issue for a strong majority of people.

In short, all my fix does is when WindowPad determine's that the window should be moved to a different monitor, the below method is called to determine whether or not the window would fit non-resized on the new monitor. This...

A) is only called when a shortcut was used for the second time (i.e. when WindowPad wants to move the window to where it's current position), so it doesn't interfere with anything else in WindowPad.
B) prevents the 'slack' monitor region ('DR' in Lexikos's previous post's diagram) from falsely triggering WindowPad into performing like there's monitor present (i.e. a third monitor in the 'DR' space would work like normal, but a 'R' monitor with extra space that reaches below the 'L' monitor won't trigger).

Then you would need to change how the 'MoveWindowInDirection' method works by wrapping the entire contents of 'if(newm != m)' with another if block that users the new method above. As an example:

* All code that was written by me in this post is hereby released into the public domain.

_________________
-Thracx

"Man wants to know, and when he ceases to do so, he is no longer a man."
-Fridtjof Nansen

Medium technically literate but not very familiar with scripting.

I am in same position as Pieter333 on page 6 of this topic. I have generated .exe file using compliler. Run the .exe and get the WindowPad icon in the systray but non of the functions seem to work.

Have also run .ahk file from AutoHotkey and same result.

Should I be placing the .ini file somewhere other than the folder that I run the .exe or .ahk file from i.e. maybe in one of the Windows system folders?

Sorry for the basic question but have searched documentation for AutoHotkey and WindowPad and can't seem to find a simple answer (well, simple to me anyway).

Desperately want to use this utility as Nvidia nview utility which came with my graphics card crashes my PC (not the only one it seems from searching Google)

Many thanks.

Double-click the tray icon and go to View -> Hotkeys and their methods, then tell me what you see. The script also sets WINDOWPAD_INI_PATH to the path it is using, so also go to View -> Variables and their contents, and check its value.

WindowPad.ini should be wherever you tell the script it is; i.e.
If WINDOWPAD_INI_PATH is empty, %A_ScriptDir%\WindowPad.ini is the default. Unless you add #NoEnv to the script, it can also be an environment variable.

Many thanks for reply.

Double clicking the tray icon and viewing "Hotkeys and their methods" shows this:

Type Off? Running Name
-------------------------------------------------------------------
k-hook CapsLock
k-hook Numpad0
k-hook NumpadDot


Section of script I think you are referring to is this:

WindowPad_Init(IniPath="")
{
global WINDOWPAD_INI_PATH
; if A_IsCompiled ; Load icons from my custom WindowPad.exe.
; {
; ; Default icon is 32x32, so doesn't look good in the tray.
; Menu, TRAY, Icon, %A_ScriptFullPath%, 11
; }
; else
if (A_LineFile = A_ScriptFullPath)
{ ; Set the tray icon, but only if not included in some other script.
WindowPad_SetTrayIcon(true)
; Use OnMessage to catch "Suspend Hotkeys" or "Pause Script"
; so the "disabled" icon can be used.
OnMessage(0x111, "WM_COMMAND")
}

if IniPath =
IniPath = %A_ScriptDir%\WindowPad.ini
WINDOWPAD_INI_PATH := IniPath
WindowPad_LoadSettings(IniPath)
}



WindowPad.ini is in same folder I run the .ahk script in/from. If I run the .exe file instead of the .ahk file, double clicking the tray icon does nothing.

Didn't understand the last bit of your reply (the bit about environment variables) as I am not really script literate. Just a user who wants the utility to work!

Hope this helps solve my issue. Many thanks for looking at this. Apologies for ignorance.


[/code]

This at least shows that the script is finding a configuration file, since there would otherwise be no hotkeys. CapsLock, Numpad0 and NumpadDot are the default "prefix" keys. Try pressing any one of these, then checking the hotkey list. More hotkeys should be registered the first time any prefix key is pressed.
The default behaviour of compiled scripts is to disable the "main window," which is generally used for debugging. It can be re-enabled by adding the following to the auto-execute section of the script (i.e. in WindowPadInit)

It wasn't relevant, anyway. Just to be sure...
...which functions did you try? WindowPad originally used Win+Numpad, but the latest version uses Numpad0/NumpadDot+Numpad or Capslock+q/w/e/a/s/d/z/x/c. If I download the latest version and extract it somewhere, it Just Works.