topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Tuesday March 19, 2024, 12:36 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Richard S [ switch to compact view ]

Pages: [1]
1
jgpaiva: No, the pm you sent me doesn't change either of the two quirks I've described above.

With a little more use under my belt now, maybe I can more precisely describe the quirk in response to which you sent me the pm:

If, when trying to left-button-drag (ie invoking GridMove) a window to an open spot on my monitor (ie where I can theretofore see Windows desktop) in order to snap it to a distant grid position, my dragging mouse crosses a pre-existing window in between, the window I am dragging jumps back to the location from which I moved it, and my GridMoving mouse instead picks up the window I cross and moves that latter window to the empty space on the monitor I'm dragging to.

I seem to encounter this problem whether or not either the window I'm trying to drag or the window I drag my mouse pointer across on the way to my destination, or both, is a previously-snapped-to window or instead a new window that has not yet been snapped to any grid position.

If I can carefully drag the window I'm trying to move so that my mouse pointer itself doesn't cross any other window, I can successfully move the window I'm trying to move to the destination to which I'm trying to move it.  So I either need an open path (ie no windows) to move along, or I need to first either drag intermediate windows out of the way or temporarily Minimize them--ie get them off my screen.

Great product.  Very usable in its current state.


2
jgpaiva: (Re the discovered bug--dragging window across another window to a third position) you've got a great program here.  Extremely useful.  I find multiple monitors to be a pain, especially if they're not the same size.  I much prefer having everything on colossal monitor--which makes your utility a godsend.

Another oddity: after I've snapped a window to a grid position, I have difficulty (perhaps impossibility) snapping another window onto the top of the previously snapped window, i.e., onto the same grid position.  In other words, a snapped window doesn't seem to like having another window snapped onto the top of it.  I seem first to have to change the shape of the first-snapped window so that it is no longer contiguous with the underlying grid position, then I can snap onto the same grid position.

I'm running Vista.

Regards.

3
Sorry for butting in here.

I use a very wide monitor, and use a custom grid: three top-to-bottom windows side-by-side.  Suppose I have windows in the left (grid-number 1) and middle (grid-number 2) positions, but none in the right (grid-number 3) position (so on the right-hand side of the monitor I'm just looking at the Windows desktop).

If I try to snap the window in position 1 all the way across the screen to position 3 by holding down my left mouse button on the left side of the title bar of the window in position 1 and dragging the window all the way across to position 3, the mouse seems to throw the window that was in position 1 back into position 1, and instead pick up the window in position 2 that I'm merely crossing over and drop that latter window into position 3, leaving position 2 now window-less (ie it's now in the middle of the monitor, position 2, that I'm looking at the Windows desktop).

In other words, I'm having a lot of trouble successfully dragging a window across another window to a third grid position.

If anybody understood that--any suggestions?

Thanks.

4
Another question, if you all don't mind.  I tried using RunDemo.grid.  Is there any way to get out of that template what the pixel co-ordinates of the saved former window position were?

I ask because I very regularly use KeyText's mouse-manipulation functionality to copy, in automated, highly-repetetive fashion, various data out of a standardized Adobe Acrobat page (ie the various bits of data are in standardized positions on the page).  For this automated copying (and pasting in another program, which then manipulates the data) of the various data in the Adobe page to work, the Adobe window has to be of the exact same size and in the exact same position on my screen each time I do this.

If I could use RunDemo.grid to move my precisely-positioned Adobe window to any other location and could then somehow extract out of RunDemo.grid what the pixel coordinates of the Adobe window were before it was moved, I could create a custom GridMove template that incorporates those pixel co-ordinates so that I could thereafter always reliably snap my Adobe window to the necessary position.

So, can I somehow get RunDemo.grid to declare the co-ordinates of the pre-move window position?

An odd request, but many thanks if anyone has ideas.

5
Many thanks.

6
Forgive the simplest of questions, but what program do you use to create a grid template?  I tried using Microsoft Word, but all I can do there is save it as a text file, not one that GridMove will recognize as a template.  Is there some text editor that will save what I create with the correct extension?  Thanks.

Pages: [1]