DonationCoder.com Software > Post New Requests Here

IDEA: drag window to edge automatically resizes it

<< < (102/146) > >>

jgpaiva:
Hi ben!

As for the "advanced text services" thing, I have no idea what causes that, but since I haven't changed much stuff since .53, I suppose it was the recompilation that caused that problem.

As for the second problem, I added that in this version but didn't predict people might use gridmove with such values (that positions the area in the middle of the titlebar, right?) and that test makes sure that the area isn't taking the whole titlebar (for small windows). Actually, in your case, you never experience that problem, since the are which you can grab the window to move it (without gridmove) is on the left. Smart :P

ebennetthill:
Thanks for the quick reply. I'm still playing with the new version. I think I still like the way the old version handled the titleleft/titlesize. The 150-355 setting gave the left side of most of my windows to grab and resize, and the right side to grab and move. There was a problem with small windows sometimes because the title extended too far across the window, but not too often. I think I might need to change more than the 3* to 2* to get it to behave like it used to.

Also, what do I change to get GridMove to handle microsoft windows the same as the old version? GridMove is not recognizing them at all now - no matter what size they are or where I click them. I'm a HS teacher and I usually have a Word document or two or three open and an Excel file too. Resizing them with GridMove was a main use of the program for me.

By the way, just as a matter of fact, I'm using GridMove on a Thinkpad Tablet with a 12" screen (pretty small).

jgpaiva:
:)
To be fair, you did a better decision than mine. Since you put that area on the right, you don't have the problem most people have with gridmove, which is that it interfeers with clicking on the office 2007 buttons. To protect people from that, I added a detection of those cases, to disabled GridMove for those windows.
You can remove that by removing the "AND MouseControl = """ clause on this code:

code inside
--- ---  if(WinWidth > 3 * TitleSize)
  {
    If (TitleSize < WinWidth - 100 AND LButtonDrag
        AND OldmouseX > TitleLeft AND OldMouseX < TitleSize
  AND MouseControl = "")
    {
      Hotkey = LButton
      sendinput {LButton up}
      GoSub,DropZoneMode
      Settimer, MousePosition,10
      return
    }
  }
  else
  {
    If (LButtonDrag AND OldmouseX > TitleLeft
        AND OldMouseX < TitleLeft + 20 AND WinWidth > 170
        AND MouseControl = "")
    {
      Hotkey = LButton
      sendinput {LButton up}
      GoSub,DropZoneMode
      Settimer, MousePosition,10
      return
    }
  }

nudone:
idea: 'throw' windows across screen to activate gridmove resizing.

(assuming this hasn't been suggested already) click and hold the windows titlebar and 'throw' it in the direction of the zone on the grid that you want to use.

so the direction of the throw determines the resize and final window position.

could work well i think for simple grid layouts.

would autohotkey be able to detect 'throws', i.e. click, hold, move mouse quickly and release hold.

(sorry if i've already said this idea before or just repeated someone else's post - it seems kind of familiar.)

mojo-chan:
I found a bug :)

When you make a window "on top", it does stay on top at first. However, when certain things happen to it, it looses the "on top" attribute.

A good example is the KeePass 2.06 window. You can make it stay on top, but if you then add an entry when the new entry window closes the main window is no longer stuck on top.

ATI Hydravision and nView seem to work okay...

Navigation

[0] Message Index

[#] Next page

[*] Previous page