IDEA: move small dialog windows to cursor position

[nudone]

https://www.donation...=302.msg2140#msg2140

this original request was made a few months ago but it appears no one was up for the challenge - so, i'm resurrecting the request with a reward for 100 DC credits to anyone that can create a satisfactory util (preferrably using autohotkey so that it would be easy to modify).

and now for a quick explanation of what i'd like:

i've a very large monitor, a 24" widescreen LCD (this may or may not be seen as an attempt at compensating for other inadequacies).

i've always been irritated (even with smaller monitors) how i have to keep moving my cursor to the center of the screen to acknowledge small dialog boxes that appear throughout the course of my pc use.

what i would prefer, is that the small dialog window would move itself automatically to fall somewhere under where my cursor is at the time of clicking the button that caused the small dialog window to appear.

e.g. CURRENTLY, i click on a button at the far edges of the screen that requires some kind of confirmation, so a small dialog window appears in the center waiting to be clicked and acknowledged. okay, i move my mouse to the center and click BUT i'm going to move my cursor back to the original area where i first clicked the initiating button as that's where i'm 'working' with OTHER buttons and things.

INSTEAD, i would click on a button at the far edges of the screen and if a small dialog window appears in the center it would then automatically jump so that it positions itself under where the mouse is. the mouse is still hovering over the button that has just been clicked.

i know, i know. there are methods for the mouse to jump to the button that is in focus but i really can't stand that way of working. it still requires me moving my attention away from where my cursor originally was and then moving it back again. and, i don't want this to work with all windows so i wouldn't want the cursor jumping around all over the screen every time a new button comes into focus.

i've attempted to create my request using autohotkey but i don't have the programming skills to make it work correctly. i can make small windows jump to the cursor but they then become STUCK to the cursor position and move around with it...

the trick would be that the dialog window jumps to the the cursor position and then releases itself so that it doesn't continuously keep trying to center itself under the cursor. you can't click on any buttons, of course, if the dialog window keeps automatically moving around.

the other point to consider is that the automatically jumping window would have to remain fully on screen regardless of whether the cursor was at the very edges, i.e. if the cursor was close to the screen edge the window would have to position itself close to the cursor but not so close it goes off the edge.

i really only want this to work for the small dialog windows that appear, things like save/open/close/'confirm file delete' or anything else of this small size.

i'd like to be able to figure all this out with autohotkey as i'm sure it is possible but i believe it would be a very quick coding snack for those of you that already know how to script. it would take me several hours/days of messing around without any guarantee that i'm heading in the right direction.

thanks for your time...

[brotherS]

i know, i know. there are methods for the mouse to jump to the button that is in focus but i really can't stand that way of working. it still requires me moving my attention away from where my cursor originally was and then moving it back again. and, i don't want this to work with all windows so i wouldn't want the cursor jumping around all over the screen every time a new button comes into focus.

-nudone (April 06, 2006, 05:17 AM)

Too bad...  I love that feature!

Btw, 92.4% of all people do - if you just force them to use it for one week to give them a chance to get used to it

Good luck with your request, I'm sure someone will come up with a solution!

[nudone]

the thing i don't like about the auto cursor jump method is that i often don't want to click the button that is in focus. so, i have to check to see where the cursor has jumped to and also spot the button i actually want to click AND then after that i move the cursor back to the area of the screen i was clicking around - i wouldn't call the 'cursor jump' method the most efficient and i'm sure there must be micro seconds lost where you have to become reorientated as to where the cursor has gone and what you are meant to be clicking on.

it may be microseconds to do all this moving around but it's a massive irritation to me.

i'll turn the auto move cursor thing on for a bit and see if i can get used to it.

[brotherS]

the thing i don't like about the auto cursor jump method is that i often don't want to click the button that is in focus. so, i have to check to see where the cursor has jumped to and also spot the button i actually want to click AND then after that i move the cursor back to the area of the screen i was clicking around - i wouldn't call the 'cursor jump' method the most efficient and i'm sure there must be micro seconds lost where you have to become reorientated as to where the cursor has gone and what you are meant to be clicking on.

-nudone (April 06, 2006, 05:37 AM)

I can't share that feeling. You actually get a very good feeling over time about where it will place the cursor and it's actually faster, not slower. I actually had several people thanking me for making them use it long enough to 'see the light'.

it may be microseconds to do all this moving around but it's a massive irritation to me.

Yeah, it's an irritation for sure, but only in the first few days. Been there, done that...

i'll turn the auto move cursor thing on for a bit and see if i can get used to it.

Great! I found mostly those resisting change of any kind can't (or won't try long enough to) get used to it (you know, people still living without CDs, DVDs, Internet, ...), so there's a good chance you'll make it!


May the force be with you

[nudone]

well, i'm still trying the auto cursor jump thingy - but it doesn't work within photoshop. this is good as i didn't want my cursor jumping around to every button that had focus but it doesn't even work when the 'are you sure about saving' dialog pops up. this wouldn't happen if my little util came about, ahem, ahem.

early days yet so i'll persevere.

[jgpaiva]

Let me se.. You want a script that would move every active dialog smaller than a given size to a place very close to the mouse?

[nudone]

Let me se.. You want a script that would move every active dialog smaller than a given size to a place very close to the mouse?

-jgpaiva (April 06, 2006, 06:13 AM)

that pretty much sums it up. like i say, i've had it working except for the bit about it releasing the window once it has moved it. it would be useful if an 'exclude' list could be used to prevent certain small windows moving maybe - but that defeats the whole point of it.

[jgpaiva]

Although it's not bullet-proof (yet ), please check if this is what you're looking for:
.exe file: http://jgpaiva.dcmem...gMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...gMove/DialogMove.ahk

[nudone]

Although it's not bullet-proof (yet ), please check if this is what you're looking for:
DialogMove.ahk

-jgpaiva (April 06, 2006, 07:07 AM)

great. it's almost there. i'm getting better results with this at the moment:

PredefWinHeight:=600
PredefWinWidth:=600

it does appear to be doing a few strange things - reducing the size of some windows to just their title bars when bringing them back into focus.

the bit about preventing the dialog box jumping to off the screen edge needs to be implemented and it would be a lot better if the dialog box centered itself under the cursor when it makes the jump - providing this doesn't conflict with the opening off the screen edge.

jppaiva, i shall try to understand your script and modify it but i would be grateful if you carried on with this little project.

thanks for the work so far. DC credits will be on their way.

[jgpaiva]

PredefWinHeight:=600
PredefWinWidth:=600

-nudone (April 06, 2006, 08:09 AM)

Yes, that was only the test value I selected, it will be costumizable.

it does appear to be doing a few strange things - reducing the size of some windows to just their title bars when bringing them back into focus.

-nudone (April 06, 2006, 08:09 AM)

That worries me. It wasn't supposed to. I will try to reproduce that.

the bit about preventing the dialog box jumping to off the screen edge needs to be implemented and it would be a lot better if the dialog box centered itself under the cursor when it makes the jump - providing this doesn't conflict with the opening off the screen edge.

-nudone (April 06, 2006, 08:09 AM)

Yes, as I said, it still isn't bullet-proof, i was only checking if this is what you're looking for.

jppaiva, i shall try to understand your script and modify it but i would be grateful if you carried on with this little project.

-nudone (April 06, 2006, 08:09 AM)

Yes, sure I will

thanks for the work so far. DC credits will be on their way.

-nudone (April 06, 2006, 08:09 AM)

How about waiting to see if someone posts a better solution?

[nudone]

ignore what i said about:

PredefWinHeight:=600
PredefWinWidth:=600

that's the bit that's making my windows go funny.

[jgpaiva]

Ok.. I did a small update, now it constrains the message boxes to the screen.
What I've been thinking about is how it somehow makes the windows act funny. Sometimes it resizes them, other times, it hides them, something is not right. But i have no command in it that could do that, so i guess i could blaim it on ahk.
BTW, does it act funny with you too?

.exe file: http://jgpaiva.dcmem...gMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...gMove/DialogMove.ahk

[jgpaiva]

I must say I'm starting to think this is a great idea. I even am trying to use it myself.
@brotherS: if you like to use the "jump to box" function, I recomend you to try this script, it's much less intrusive than that method, and it allows for a better flow of work (and i know you love stuff that improves your flow of work )

Still, i get a bit of an erroneous behaviour, which if I don't find the solution to, I will post at AHK's forum, since this shouldn't be happening.
Any opinions, nudone?

[nudone]

i'm about to try the new version now, jgpaiva, so i'll report back soon.

it would be very interesting to hear what brotherS thinks to all this. i've been convinced for years that this method would be a significant improvement on gui functionality and is also the most logical when you think about it - afterall, why should a dialog window always popup in the center of the screen? other windows often remember their last closed positions and now that we've moved away from 640 x 480 resolutions screens there's a lot of 'desktop' to cover.

think of it this way: if you are using a dual monitor set up, i'm sure you'd find it annoying having to 'spot' and 'click' on a dialog that popped up on the opposite monitor you were working on. even with the cursor jump method you'd still have to move your cursor a full screen back to the original monitor - that is simply a bad gui method. okay, i know many apps will open up their dialogue windows on the correct monitor the main app is running on but i've certainly used others that don't quite understand how to behave with a dual monitor arrangement. my method would cure that.

[nudone]

i'm wondering is this perhaps going to work better with a preset list of small dialog windows that it should operate with?

this would stop the strange shrinking window effect on the windows that suffer from this and it would also prevent other things i've just noticed - one of my winamp windows (that is quite small) jumped around when i didn't want it to.

as the main annoyance that prompted me to suggest this method was from the small system dialogs that appear throughout the day, i think a simple list could be made so that 'dialogmove' could just catch them on opening.

the list would include all the usual culprits (these are the from their title bars):

confirm file delete (after clicking empty recycle bin)
save
open
find
confirmation
end program

i'm sure there are more but i can't get any to appear at the moment as i can't think what would bring them up.

there also appear to be awkward small dialog windows that would have to be catered for. for example: when photoshop asks if you want to save a file the dialog that pops up says 'Adobe Photoshop' in its title bar and then 'save...' in the text below.

i'm going to try and get my script working again that i had done before and see if it also has the shrink window problem.

[jgpaiva]

You know what? For me, the main anoyance in the jumping mouse method isn't having to go back to the place, is that the position of the mouse in the sreeen relative to the physical position of it changes. Ie, I will have to raize my mouse from the floor for it to be right with the mouse on the screen. (I don't think i explained myself decently)

I don't think that's the right way to solve the problem (by ignoring it and creating a list of windows it should use), since that would take some use of it. If there would be new dialogs appearing, it'd ignore them. But I'll add both functionalities, a ignore list and a "move list", when one is clear, the other one will be used. I might release a new version with that funcionality tomorrow afternoon, i think. (GMT)

[nudone]

thanks, i look forward for the new release...

good point about the position of your hand on the mousemat and the location of the cursor after the 'jump cursor' method - that is another annoying thing about it i agree.

it may also be more 'pleasing' if 'dialogmove' knew if the cursor was already close to the dialog window that appears.

if the cursor is already within 200 pixels (or whatever distance) to the small dialog window then 'dialogmove' wouldn't do anything. i feel this would look better as there really isn't a need for such small jumps and the eye does't then need to 'spot' the position of the window 'jerking' about.

[noth(a)nk.you]

Not be a nay-sayer, but I prefer using my left hand on the keyboard when I'm mousing.

It allows access to frequently used key-combos (Ctrl-S) and would in your case allow to cycle through the options of a dialog box (Tab) and confirm your selection (Space).  If you can predict what dialogs are coming up, you might even be able to move your cursor toward the next task and let your other hand deal with the boxes.

Food for thought.

[nudone]

i know what you mean, noth(a)nk.you, and there are times when i find touching the mouse very irritating and prefer to work primarily with the keyboard. and, of course, there are times when it's necessary to use mouse and keyboard in harmony - photoshop demands it.

but i suspect that i'm not alone when i'm using the computer and my left arm seems completely redundant - keeping my left hand on the keyboard at all times just for the occassional dialog box confirmation isn't really what i'd call comfortable. okay, moving ones hand from it's resting place to the keyboard every now and again isn't such a terrible thing, but i think the point in all this is that 'small' actions can seem like 'big' annoyances when working with a computer, especially as they accumulate throughout the day.

i want things to 'flow' when i'm interacting with the windows interface. it seems to me that common gui's haven't really progressed much over the past couple of decades - i was just trying to address a little part of it that i find 'illogical'.

[jgpaiva]

it may also be more 'pleasing' if 'dialogmove' knew if the cursor was already close to the dialog window that appears.

if the cursor is already within 200 pixels (or whatever distance) to the small dialog window then 'dialogmove' wouldn't do anything. i feel this would look better as there really isn't a need for such small jumps and the eye does't then need to 'spot' the position of the window 'jerking' about.

-nudone (April 07, 2006, 03:10 AM)

I had already thought of that, but still didn't finish implementing it. As you can see now, it already checks if the box is below the cursor, and in that situation, doesn't move it. But i will finish that, and create those limits.

[edit](actually, that piece of code is there, but it looks like it's not doing anything)[/edit]
[edit2]i fixed the bug mentioned here^ you can get the latest version from :
.exe file: http://jgpaiva.dcmem...gMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...gMove/DialogMove.ahk [/edit2]

[AndyM]

i'm wondering is this perhaps going to work better with a preset list of small dialog windows that it should operate with?

this would stop the strange shrinking window effect on the windows that suffer from this and it would also prevent other things i've just noticed - one of my winamp windows (that is quite small) jumped around when i didn't want it to.

-nudone (April 07, 2006, 02:56 AM)

I had a few small windows I didn't want moved (the Online window from
DYDLO, a clock and stopwatch from an alarm utility I use).

So I added a few lines near the end of the FindWindow: section of the
code:

[Select]

If WinWidth > %PredefWinWidth%
  return
IfWinActive, ahk_class TformClockFloatingForm
  return
IfWinActive, ahk_class TformStopwatchFloatingForm
  return
IfWinActive, Online
  return

Now these windows don't move.

[jgpaiva]

Yes, that does work, Andy, but it's not easy to use. I'll add a better ay to do it, i'm just trying to solve the strange windows behaviour

[nudone]

if it helps any, the strange window shrinking i have is with windows that contain tabs with panes inside. so far it does it with 'maxthon' and 'notepad++', i've not seen any strange shrinking with other windows.

i'm really looking forward to the final version, jppaiva.

[noth(a)nk.you]

I was just looking through my computer and found ATI Hydravision, which had this option:



This might only work for multiple monitor setups (does not seem to do anything for me), but it's probably worth checking out.

Edit: It's confirmed, you need multiple monitors set up in order for this feature to work.

[nudone]

oh well, it looked promising for a minute.