Im having a random issue where when I left click on the title area to begin dragging into a grid, sometimes gridmove completely locks up my computer for 1minute (mouse frozen), then shows the grid layout, then 30 seconds later mouse moves a bit more, and if i press esc a bunch of times, maybe 45 seconds later it cancels. Restarting the software makes the issue go away (eg: software works as expected). FYI: i leave my computer on for weeks at a time, going to standby overnight. Can you think of some kind of memory leak or something that could cause this? Anyone experience this before? Could my grid be at fault? I can post it if needed..

Also minor: when i accidentally double click on the title (within the 100pixels) it sometimes jumps to the wrong monitors grid. Any thoughts?

Thanks! It really is great software when it works, but having it lock up my computer when I have documents open is a bit scary..... If we resolve this issue, I would definitely be willing to donate some funds.

To be honest, I'm not sure why this would happen. Regarding memory leaks, you can check how much memory it is using the next time it happens (after it unfreezes the computer) by pressing ctrl-shift-esc to show the task manager and looking for the "memory" column. However, the language used to program GridMove does all the memory management, so I wouldn't expect this to be happening. I'm 100% sure it isn't related to your grid. I've tested GridMove with very complex grids (some with 100+ parts!) and even though it was slower and took some time to load, this never happened.Can you tell me if this happens in the first few hours after you start GridMove? If not, I could set a timer for it to restart itself every day or something like that. (it's not the best solution, but it might work )

re: minor. GridMove should already take a few miliseconds and require the mouse to move to activate, but I fear that if these settings are too large, GridMove would become less responsive. Have you tried the middle button method? Its simpler and more reliable, I think.

Thanks for your suggestions. I never got a chance to see if the memory usage spiked as the system was too "locked up" to open task manager. Makes sense that autohotkey would take care of that stuff anyways.

I took your suggestion and use a different method, so I use drag to edge to activate gridmove instead of mouse click. Middlemouse button does not work with my logitech G5 laser mouse w/ setpoint software running. So i dont get the double click issues (i routinely dc on titlebar to maximize a window)

Just to give you an update on the lockup issue, it seems to have fixed itself, kinda of.Reproduce:-wake up computer from sleep (after being off all night)-try to do a gridmove

The slow down always happens when I do that. It doesn't seem so severe now, i just wait it out the 5-10 seconds. A second gridmove attempt is back to normal speed. So its like its re-caching the grid or something that takes time. I don't reset the software to get the normal behavior back. So i guess it could be the drag method on titlebar that caused it, due to your script or due to ahk's implementation, or perhaps my mouse is to blame, it does report at 2000 reports/second (rather fast).

Im having a random issue where when I left click on the title area to begin dragging into a grid, sometimes gridmove completely locks up my computer for 1minute (mouse frozen), then shows the grid layout, then 30 seconds later mouse moves a bit more, and if i press esc a bunch of times, maybe 45 seconds later it cancels. Restarting the software makes the issue go away

Let me guess, Windows XP or any other 32bit Windows version? I had the same issue too, I think its due to gridmove getting swapped to the page file and having to be swapped back. I tried looking for ways to keep it from getting paged, but came up empty. I finally switched over to 7x64 with lots of ram it never happened again.

Im having a random issue where when I left click on the title area to begin dragging into a grid, sometimes gridmove completely locks up my computer for 1minute (mouse frozen), then shows the grid layout, then 30 seconds later mouse moves a bit more, and if i press esc a bunch of times, maybe 45 seconds later it cancels. Restarting the software makes the issue go away

Let me guess, Windows XP or any other 32bit Windows version? I had the same issue too, I think its due to gridmove getting swapped to the page file and having to be swapped back. I tried looking for ways to keep it from getting paged, but came up empty. I finally switched over to 7x64 with lots of ram it never happened again.

makes perfect sense too. It happened again today, when i was using 99% of my ram (several virtual machines), and i accidentally moved a window, and solid 5minute lockup. Plus gridmove uses 10% of my quad core 3.2ghz processor which doesn't help when your out of ram... Same thing when you first get out of standby, probably from not using for so long it got paged out... I guess we can consider it solved! thanks

@kevinf: I find it strange how GridMove takes so much more time to answer again than it would take to start up, or do you also experience slow starts like that? Also, after it takes those 5minutes to get back, does it then start acting normal or does it still need a restart?

I absolutely love Gridmove, and I've recommended it to several friends. It doesn't seem to be compatible with the latest versions of Firefox. That browser has moved away from having a normal toolbar to having 1 dropdown menu in the top left corner. Whenever I click the drop down menu, Gridmove detects the window as being moved against the edge of my screen, and will re-size it. I've set Gridmove to ignore Firefox, but it would be nice to have Firefox work as normal and be able to re-size it with Gridmove.

ghostsquad: have you tried using gridmove with the middle-click method? Its much faster because it works anywhere on the window, and it does not have that kind of trouble with strange apps (which unfortunately are more and more frequent)

First: Thanks for the great program. On a Full-HD screen, this is a must-have. You cannot browse the web with 1920px width browser-window as a lot of sites use 100% width and therefore reading texts is painful. But half of 1920px is not enough (windows 7 makes half the screen easy). So your app makes this work in a cool and easy way.

But I have kind of a problem: When I plug in my external monitor into my laptop, I need to restart GridMove because the external monitor has another resolution. Couldn't Gridmove detect whenever I plug an external monitor in or out and restart itself? This would be very helpful.

Actually, that was a feature of GridMove, but it caused random restarts to too much people, and I ended up disabling it.Right now, I guess the best way to do it is just to press win+g (to show the command window) and then 'r' (to restart GridMove).

okay, thanks for the info and the tip with the shortcut. That's already a bit better. Maybe you could make the feature optional and turn it off by default? So people that want the feature although it might cause random restarts can turn it on whereas people that do not need it or do not want random restarts could turn it off?

How did you detect this? Event listener that is called when devices change? I think you might be able to check the resolution every few seconds and if it changed, restart GridMove. Or when the event was fired, you could check whether the resolution really changed and only restart if it did.

I found this utility as I was looking for a way to define Windows for certain programs to be placed on a specific screen and a specific size. This looks like it *ALMOST* fits the bill. Which leads to this suggestion: I'd like to be able to define certain programs to automatically go to a certain grid location - doable?

I found this utility as I was looking for a way to define Windows for certain programs to be placed on a specific screen and a specific size. This looks like it *ALMOST* fits the bill. Which leads to this suggestion: I'd like to be able to define certain programs to automatically go to a certain grid location - doable?

WinSize2 may do what you want. But you have to position the windows manually, then press a hotkey to memorize size and position. The first time that window opens with WinSize2 running, it will move and size it if needed.

I found this utility as I was looking for a way to define Windows for certain programs to be placed on a specific screen and a specific size. This looks like it *ALMOST* fits the bill. Which leads to this suggestion: I'd like to be able to define certain programs to automatically go to a certain grid location - doable?

WinSize2 may do what you want. But you have to position the windows manually, then press a hotkey to memorize size and position. The first time that window opens with WinSize2 running, it will move and size it if needed.

Is there a way to change the color of the "selected grid". Right now it is a milky white and for some reason, I can hardly see it... It would be great if I could make it blue for example. I also don't understand why the numbers and lines fade out behind the selection grid. They should remain clear and the selection color should make it obvious what the selection really is - not the numbers fading out.

Hopefully this is possible with changing an .ini file or something...

Overall though, this seems like a great program. I've made a new grid which maybe others would like... where do I upload it?

Is there a way to change the color of the "selected grid". Right now it is a milky white and for some reason, I can hardly see it... It would be great if I could make it blue for example. I also don't understand why the numbers and lines fade out behind the selection grid. They should remain clear and the selection color should make it obvious what the selection really is - not the numbers fading out.

Hi,There is no way to change the color of the overlay except byt editing the code itself, honestly it never occured to me that someone might wish for a different color there

Regarding the error, it wasn't supposed to happen. I think the source code version isn't exactly the same (I had a problem with my laptop and lost some GridMove code a while ago), so it may actually be a bug.That might explain the different file sizes of the compiled version, but probably it's only because you compiled it with a newer version of AutoHotkey which must include a larger runtime environment.

If you'd like, I have a newer (unreleased) version of GridMove which I can send you. Hopefully it will not have that bug. Just contact me through email so I can send it to you!

On your forum user page, you list a homepage which then has a link to your contact email. I sent the e-mail there. But then I realized you may have simply meant to send you a private message "email" through this forum instead which makes more sense. I should have just done that...

Hopefully you got the email. I can send it again through "private message" if you didn't receive the first one.