AutoHotkey Community

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

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!

Ah, okay. The "last edit date" is at the bottom of the post, in small lettering:
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

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.

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: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.

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".)
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.

That's strange. If you can tell me:

• which version of Windows you are on, and
• the positions and sizes of your monitors,

I might be able to reproduce the problem. (If not, fixing it will be more difficult.)

There isn't much difference. For instance:This is roughly equivalent to...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.
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:while manually restoring, moving and maximizing the window put it at: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.
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.

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: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:WindowPad_INI_GetList() gets a list of "Hotkey" values from the "Hotkeys" section of the ini file. Examples:(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,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.)

Yes - it is the only way to allow hotkeys to be customized without editing the script itself.
Couldn't have said it better myself.

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

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.

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:'*' lets the hotkey trigger when any modifier keys are pressed, and {Blind} tells it not to automatically release any modifiers for the Send.

I appreciate the quick response! Worked like a charm

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?