Just thinking out loud here, since i am not supposed to do any more work on gridmove until smewhere next week.
I'm thinking that there's an easy solution to the problem. Something like this:
Using the same method of the "Maximize horizontally/vertically" function, some grids could be "special". It's width and height could be specified in a per-app basis. The application and the width and height of the grid could be specified on the .ini file. Since most of the code comes from gridmove, this shouldn't be much of a problem.
As for having other stuff there, nudone, it isn't really that difficult. Using the exact same method descibed above, i could create another "special" grid that would execute one program when hightlighted
. So, if it launched ahk scripts, anything is possible.
(i'm not sure about the click start menu function, though, it might take too much time to launch the script)
@Mouser: you are right, that MUST be implemented, a stupid thing has happened to me a bunch of times already: Moving those not-resizeable windows (like gridmove's about box) to the grid, and then not being able to get them to their original size. DialogMove already has code that keeps track of open windows an their size (the window buffer), so this shouldn't be much of a problem.
The only problem is how to make it return to the original size.
My suggestion is: if the mouse isn't highlighting any of the grids when the window is dropped, make it resize back to it's original state.
Another way would be to have yet another special grid element, specified with something like:
1triggerleft = 0
1triggeright = 30
1triggertop = 0
1triggerbottom = 30
1gridtop = restore
1gridleft = restore
1gridright = restore
1gridbottom = restore
which wouldn't be a problem either (notice that, to make the size of the grid file smaller, 1gridleft 1gridright 1gridright could be ommited altogether, since they will never be read.)