-
https://www.donationcoder.com/forum/index.php?topic=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...
-
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
Too bad... :( I love that feature! :up:
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 :D
Good luck with your request, I'm sure someone will come up with a solution!
-
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.
-
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
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 :D
-
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.
-
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?
-
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
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.
-
Although it's not bullet-proof (yet ;)), please check if this is what you're looking for:
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
-
Although it's not bullet-proof (yet ;)), please check if this is what you're looking for:
DialogMove.ahk (http://jgpaiva.dcmembers.com/DialogMove.ahk)
-jgpaiva
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.
-
PredefWinHeight:=600
PredefWinWidth:=600-nudone
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
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
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
Yes, sure I will ;)
thanks for the work so far. DC credits will be on their way.
-nudone
How about waiting to see if someone posts a better solution?
-
ignore what i said about:
PredefWinHeight:=600
PredefWinWidth:=600
that's the bit that's making my windows go funny.
-
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.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
-
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?
-
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.
-
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.
-
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)
-
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.
-
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.
-
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'.
-
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
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.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk [/edit2]
-
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
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:
If WinWidth > %PredefWinWidth%
return
IfWinActive, ahk_class TformClockFloatingForm
return
IfWinActive, ahk_class TformStopwatchFloatingForm
return
IfWinActive, Online
return
Now these windows don't move.
-
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 ;)
-
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.
-
I was just looking through my computer and found ATI Hydravision (http://www.ati.com/products/Hydravision/index.html), which had this option:
[ You are not allowed to view attachments ]
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.
[ You are not allowed to view attachments ]
-
oh well, it looked promising for a minute.
-
I have good news.
I have implemented the new funcions.
At the beggining of the script, you'll find 2 variables names "DetectableWindows" and "NotDetectableWindows".
If you set any of them to some value, they wil be considered. I.E. if you set "DetectableWindows" to Open§Run§Save As§Save, it will only detect those windows. If you don't set it to anything, it will detect all windows but the ones on the "NotDetectableWindows" variable.
I've tested it a bit, and it looks like it's working quite well now, no strange behaviours anymore! :D
(BTW, if you want this to work with open/save dialogs, you might have to increase the detectable windows size)
[edit]When i mean the script has no problems, i mean it works very well if you set it some "DetectableWindows". As for the other problem, I was unnable to solve it, and have already posted at AHK's forum.[/edit]
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
-
I have 5 windows I don't want to move, so I had added:
IfWinActive, ahk_class TformClockFloatingForm
return
IfWinActive, ahk_class TformStopwatchFloatingForm
return
IfWinActive, Online
return
IfWinActive, Calculator
return
IfWinActive, Volume Control
return
With the new script, if I want to move everything else, I assume I would set
DetectableWindows=
Would I have 5 lines beginning with "NotDetectableWindows=", one for
each window, or would it all be shown on one line? How would it look?
-------------------
Btw, if anyone else is interested in not having windows moved
underneath the task bar, I changed
If (MouseY + WinHeight/2 > ScreenHeight)
FinalWinY := ScreenHeight - WinHeight
to
If (MouseY + WinHeight/2 > ScreenHeight)
FinalWinY := ScreenHeight - WinHeight -50
Andy
-
With the new script, if I want to move everything else, I assume I would set
DetectableWindows=
Would I have 5 lines beginning with "NotDetectableWindows=", one for
each window, or would it all be shown on one line? How would it look?
To use that function, you need to set:
DetectableWindows=
NotDetectableWindows=Online§Calculator§Volume Control
But this only works for the titles of the windows, you cannot use ahk_class. But that's a good point, I've changed it.
So, to ignore the windows you mentioned, the 2 variables should be set like this:
DetectableWindows=
NotDetectableWindows=Online§Calculator§Volume Control§ahk_class TformStopwatchFloatingForm§ahk_class TformClockFloatingForm
Don't forget to get the new version (.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe .ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)
Btw, if anyone else is interested in not having windows moved
underneath the task bar, I changed
Good point, I'll add 2 variables to prevent that. But the way you mentioned, only works for people with the taskbar at the bottom of the screen ;)
-
thanks for all the great work so far, jppaiva. DC credits will be on the way shortly. i'm just trying to get things working here but i'm not really finding a way to avoid the shrinking window problem.
i've also noticed that in the code above you put 'DetectableWindows' and 'NotDetectableWindows' shouldn't both of these variables (or constants, i can't remember the terminology) have the 's' taken off of them so they match the rest of your code?
if i could just get 'maxthon' and 'notepad++' to stop shrinking i'd be very happy.
-
thanks for all the great work so far, jppaiva. DC credits will be on the way shortly. i'm just trying to get things working here but i'm not really finding a way to avoid the shrinking window problem.
-nudone
The problem still is there, but it doesn't happen if you set something in the DetectableWindows variable.
i've also noticed that in the code above you put 'DetectableWindows' and 'NotDetectableWindows' shouldn't both of these variables (or constants, i can't remember the terminology) have the 's' taken off of them so they match the rest of your code?
-nudone
No, not really, the thing is that there is a 'DetectableWindow' function that checks if the title or class of the current window is in the 'DetectableWindows' variable (defined at the beggining of the code). I'm sorry, but i'm really lousy at coming up with names for such things :(
On the next version, this script will go .exe, which means it'll have a .ini, and setting this options will be easier.
Have you tried setting the DetectableWindows to "open§run§some other dialogs you want§"? it should make the shrinking windows problem go away...
-
ah, right, i see. i was changing the wrong variables then. i'll try it now. thanks.
er, oh well, i'd not even seen the functions at the bottom. serves me right.
-
it's a real shame about the shrinking windows problem but on the other hand the method for specifying windows to look for and move appears to make things a bit quicker on my machine (i could be imagining it).
also it's a pity that the window is visible before it is moved to the cursor location but we can't have everything.
i'll wait for the final exe version before making my final comments.
-
it's a real shame about the shrinking windows problem but on the other hand the method for specifying windows to look for and move appears to make things a bit quicker on my machine (i could be imagining it).
-nudone
You are ;)
When you specify the windows to be detected, it executes more lines of code (the part where it checks if the window is to be moved).
About the shrinking windows.. I already gone crazy with it, but couldn't solve it, and at the AHKforum, i'm not getting much feedback (which just means i'll have to post again). But i hope it'll be solved.
also it's a pity that the window is visible before it is moved to the cursor location but we can't have everything.
-nudone
Yes, unfortunatelly, for this method, this always has to happen, it also anoys me a bit. But I sure am open to suggestions if anybody else knows a better solution! (skrommel? ;) )
-
it does feel a bit crippled at the moment with it only matching specific windows on my machine. fingers crossed that there is a solution for the shrinking windows. does it still shrink windows if the script looks for windows that are 'smaller' than a set dimension rather than exiting when it finds a window that is larger than the currently set dimensions?
-
jgpaiva-
Thanks for adding the code to Detect Windows by ahk class, works like a charm.
Btw, I've never had the shrinking window problem you and nudone have experienced (running XP Pro, SP2).
-
Btw, I've never had the shrinking window problem you and nudone have experienced (running XP Pro, SP2).
-AndyM
do you use any progams that use 'tabs' or window panes inside the main 'parent' window? i've only had the shrink window problem with these types of programs. i imagine that the window properties get messed up in these kinds of programs so that autohotkey doesn't know how to treat them. maybe jgpaiva can say if things are not quite like that.
-
do you use any progams that use 'tabs' or window panes inside the main 'parent' window? i've only had the shrink window problem with these types of programs. i imagine that the window properties get messed up in these kinds of programs so that autohotkey doesn't know how to treat them. maybe jgpaiva can say if things are not quite like that.
-nudone
I think QuickBooks has windows like what you are talking about, but things have been ok there as far as I can tell (I don't use QB that often).
-
I really like the way this is going. It's becoming quite a good script.
I still couldn't solve the problem (unfortunatelly, i'm not having much feedback at AHKforum either :( ), but i found a small workaround.
it does feel a bit crippled at the moment with it only matching specific windows on my machine.
-nudone
The problem was that it was looking for a complete match, so, it wouldn't work with windows that displayed a path on the title bar, or something like that. It's fixed now, for example, if you set the variables to:
DetectableWindows=PSPad,testmessage
NotDetectableWindows=ahk_class TMainForm,ahk_class Winamp v1.x,Autohotkey Help
It'll detect any windows with "PSPad" or "testmessage" on it's title, wherever that string is found on the title.
It'll not detect find and run robot (the first parameter, makes that, because it's the farr's winclass), nor winamp's windows (defined by the "Winamp v1.x" class), nor it'll move Autohotkey Help file, since it has that string in it's name.
Notice that now, these values have to be CSV (comma separated values).
It now has a new hotkey (F9), which allows you to add a window to the "NotDetectableWindows" variable. IE, you find a window that gives you problems, press F9 with it activated, and next time it won't be detected. No more problems with that.
Another good adition is the ability of setting upper, lower, right and left margins. This can be acomplished through ScreenTop, ScreenBottom, ScreenLeft and ScreenRight.
I also added a .ini file for configuration, and this script also has gone .exe, which means that people without AHK installed can use it too! :)
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
-
brilliant. that's made a big difference. using the F9 key has solved my shrinking windows woes.
i do find that i get better results with the PredefWinHeight value to more than 400, say, 500 pixels. not really had time to test things with normal use so i can't say which system windows will or will not be caught be this value.
it all seems to be working pretty well to me at the moment so i have to say i'm thrilled with what you've been able to do.
if you think of further improvements it would be great to hear of them. the only things i can think of are cosmetic so aren't really worth mentioning.
-
DetectableWindows=PSPad,testmessage
It'll detect any windows with "PSPad" or "testmessage" on it's title, wherever that string is found on the title.
-jgpaiva
But if the window with "PSPad" somewhere in it's title is bigger than PredefWinHeight/Width it still won't move it. At least it doesn't appear to.
If I'm right, can you fix DetectableWindows= to override any other exclusion?
Andy
-
That's true, Andy. I think what you required can be done and makes sense, I'll try to do it. ;)
if you think of further improvements it would be great to hear of them. the only things i can think of are cosmetic so aren't really worth mentioning.
-nudone
Yes, that's a good point, i need to add an about box and a version number, now that it's got to a fully working version. (almost :( )
-
Yes, that's a good point, i need to add an about box and a version number, now that it's got to a fully working version. (almost :( )
-jgpaiva
let the revolution begin...
-
I still didn't add it the "good looks", but i already have a screenshot for it, and changed 3 things:
- It now always moves windows if they're in the "DetectableWindows" list,
- Even if there is something in the "DetectableWindows", it still moves windows smaller than the given size (i need your opinion on this)
- Added a version number at the beggining of the source code.
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
PS: please notice that the dowload link changed. (I'll edit all my posts on this thread now)
[edit] should i add a hotkey for adding a window to the DetectableWindows list? [/edit]
-
definitely add a hotkey - the more user options the better.
it might be too early to say how the 'final' version should work. maybe it requires that there are several user 'modes'.
i'm just playing around at the moment with it moving larger windows than what i originally hoped for.
this does work well for the most part but i've also noticed one annoying thing. as a new dialog is found it moves it to the cursor - great. that's good. but if there are other small windows that you have got open at the same time they obviously jump to the cursor as they become the window with focus. this is what you'd expect to happen of course as that is what 'dialogmove' is meant to do.
but...
if the small windows have been manually positioned on screen and they have been open for a while then it isn't required that they jump to the cursor. really, it's only the 'new' dialog windows that appear that ought to jump - not the ones you've positioned. i know this is extending the definition of what i originally requested but i'm wondering could a 'buffer' be built into the script so that manually positioned windows stay were they are until they have been closed. on opening again they would be 'new' and so would be expected to jump to the cursor again.
as for the several modes i speak of, i'm thinking along the lines of 'yes' to the new features you've mentioned above - that seems an essential feature to have. but how about trying to cover every eventuality. so, can we have 'detectable' windows always move, 'notdetectable' windows never move, windows below a particular 'height' always move (system dialog messages appear to be quite short in height and can be quite wide), windows below a set height and width move or don't move depending the users preference, windows above a set height and width never move (maybe that redundant).
er, i think there was more but i can't think now, maybe that was all there was. i'm just trying to think how 'dialogmove' can work in a 'fuzzy' way as there appears to be a grey area of what is expected to move and what isn't.
-
is that last version working correctly, i'm finding that it's moving every window i open not just the small ones.
-
I take your point, i've been anoyed by that problem too.
The buffer idea might solve it, I'll try implementing it. Shouldn't be much of a problem doing it, i'm only afraid it'll take more time.
I'll try, and we'll see! ;)
You're right, there was an error in the code, and every window was being moved. It's fixed now.
I also added the hotkey to add the window to the detectable windows. F10 is now associated with that function.
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
I just found a huge bug. I'm trying to fix it, but it might take some time. I'll post again when fixed.
[edit]ok, it looks like it's fixed. Please get the latest version. Be sure you don't have V1.3.x, since that one's VERY buggy[/edit]
-
great. i know you can do it, jppaiva. :D
-
I take your point, i've been anoyed by that problem too.
The buffer idea might solve it, I'll try implementing it. Shouldn't be much of a problem doing it, i'm only afraid it'll take more time.
I'll try, and we'll see! ;)
You're right, there was an error in the code, and every window was being moved. It's fixed now.
I also added the hotkey to add the window to the detectable windows. F10 is now associated with that function.
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove.ahk
I just found a huge bug. I'm trying to fix it, but it might take some time. I'll post again when fixed.
-jgpaiva
oh dear, i thought it was working quite well.
can i just also ask if you implemented the 'not move the window if it's already close to the cursor' feature. the dialogs that do jump seem to jump even when the cursor is very close to them - even if the cursor is within a few pixels of the dialog's edge.
-
oh dear, i thought it was working quite well.-nudone
To fix the windows moving too much, i made them not move at all. It is right now, i changed a few stuff, but i still get the damn shrink windows effect. (although i got a step closer to understanding it today)
can i just also ask if you implemented the 'not move the window if it's already close to the cursor' feature. the dialogs that do jump seem to jump even when the cursor is very close to them - even if the cursor is within a few pixels of the dialog's edge.
-nudone
Oh, i had forgotten that one. Right now, it doesn't move the box if the cursor is already over the box. But that feature makes soo much sense. I'll try adding it tomorow, when i should be adding the buffer feature too.
-
really, it's only the 'new' dialog windows that appear that ought to jump - not the ones you've positioned. i know this is extending the definition of what i originally requested but i'm wondering could a 'buffer' be built into the script so that manually positioned windows stay were they are until they have been closed. on opening again they would be 'new' and so would be expected to jump to the cursor again.
-nudone
I sure hope this feature can be toggled off if it's implemented.
Windows I position I never want to jump to the cursor. Windows I want to jump I'll always want to jump (I like the window jumping to just above the taskbar when I give them focus by clicking on a taskbar button).
It seems like this is a feature that would make it easier to position the window the first time it appears, since it would be right at the cursor. Is this really worth it?
Btw, howcum I've never had the shrinking problem? (not that I'm complaining)
-
I sure hope this feature can be toggled off if it's implemented.-AndyM
Don't worry, it sure will be toggable.
Windows I position I never want to jump to the cursor. Windows I want to jump I'll always want to jump (I like the window jumping to just above the taskbar when I give them focus by clicking on a taskbar button).-AndyM
Sorry, i don't quite understand what you mean.
Btw, howcum I've never had the shrinking problem? (not that I'm complaining)
-AndyM
You know what? you might have the solution for the our problem! :D
Let's try to find out why you don't have the problem. Please tell me:
- what's the AHK version you have? (if you double-click the tray icon, it's at the window title)
- if you open the AHK help file and try minimizing and restoring it through the taskbar button (by clicking it repeatedly), doesn't the window eventually disappear? (please try this with a "clean instalation" of the script, IE, without having any .ini file at the directory. please use the latest uploaded version, since it's the only that creates a .ini without any NotDetectableWindows.)
-
You know what? you might have the solution for the our problem! :D
Let's try to find out why you don't have the problem. Please tell me:
- what's the AHK version you have? (if you double-click the tray icon, it's at the window title)
- if you open the AHK help file and try minimizing and restoring it through the taskbar button (by clicking it repeatedly), doesn't the window eventually disappear? (please try this with a "clean instalation" of the script, IE, without having any .ini file at the directory. please use the latest uploaded version, since it's the only that creates a .ini without any NotDetectableWindows.)
v 1.0.42.03
repeatedly clicked on the helpfile's taskbar button and after a dozen or so cycles of minimize and restore, the help window shrunk to about an 1 1/2" titlebar.
I followed your instructions and used a clean v 1.5 script, and it created a new .ini.
I should say that otherwise, I don't use the .ini file. I was getting mixed up when modifying and reloading the script (and don't want to use F9 and F10), so I vanished the last part of the code reading and writing the .ini file, and all references to it. I'd rather have everything in one place.
But the short time I used the .ini file, I didn't have shrinking windows, other than the Help file thing.
The Help screen shrinking does happen even with the code without the .ini file (but it seems to take more clicks, 2 dozen?, to make it shrink.)
Windows I want to jump I'll always want to jump
Even if I've moved the dialog box, and then gone on to something else, I'll still want the dialog box to jump if I give it focus by clicking on it's taskbar button. Viola, it jumps to just above the button, right above my cursor.
I am enjoying the way the script is working ;)
-
Just thought of something else.
If I didn't have my botton margin preference set to 60, so all windows don't jump below my two-row high Taskbar, the shrunk Help window would have "disappeared" under the taskbar.
Instead, when it shrunk to a 1-2" wide title bar, it jumped to just above the taskbar button.
-
v 1.0.42.03-AndyM
That's similar to mine, so that can't be the problem.
repeatedly clicked on the helpfile's taskbar button and after a dozen or so cycles of minimize and restore, the help window shrunk to about an 1 1/2" titlebar.-AndyM
That looks like you also have the problem, but the prior versions were making it not appear, since when you specified DetectableWindows, it wouldn't detect any window other than the ones in that list. Still, it looks like for you, it takes more cycles for it to break. I need to make a big thing out of this in the ahk forum, i believe it should be a bug in the way AHK gets the window sizes.
I should say that otherwise, I don't use the .ini file. I was getting mixed up when modifying and reloading the script (and don't want to use F9 and F10), so I vanished the last part of the code reading and writing the .ini file, and all references to it. I'd rather have everything in one place.-AndyM
For not having the hotkeys, you could have set the "hotkey" variable to false :P
But the short time I used the .ini file, I didn't have shrinking windows, other than the Help file thing.
-AndyM
That's most probably because you don't have any apps where this happens. I also only have 2 or 3 of them.
Even if I've moved the dialog box, and then gone on to something else, I'll still want the dialog box to jump if I give it focus by clicking on it's taskbar button. Viola, it jumps to just above the button, right above my cursor.-AndyM
Ok, i understand your point. But don't worry, you'll still be able to use it like that.
-
Just thought of something else.
If I didn't have my botton margin preference set to 60, so all windows don't jump below my two-row high Taskbar, the shrunk Help window would have "disappeared" under the taskbar.
Instead, when it shrunk to a 1-2" wide title bar, it jumped to just above the taskbar button.
-AndyM
Yes, that's the behaviour i get now, too, since i added that margin.
-
That looks like you also have the problem, but the prior versions were making it not appear, since when you specified DetectableWindows, it wouldn't detect any window other than the ones in that list.-jgpaiva
Just to be clear, until a day or two ago, there was nothing after DectectableWindows= in my script.
I should say that otherwise, I don't use the .ini file. I was getting mixed up when modifying and reloading the script (and don't want to use F9 and F10), so I vanished the last part of the code reading and writing the .ini file, and all references to it. I'd rather have everything in one place.
For not having the hotkeys, you could have set the "hotkey" variable to false :P
-jgpaiva
-AndyM
Understood. I just mention that I don't need the hotkey function, so not having an .ini file doesn't cause me a problem.
-
To force dialog boxes under a certain height (130) to bypass the other
height and width filters, I added the fifth and six lines below.
If NotDetectableWindow(WinTitle,WinClass)
return
If DetectableWindow(WinTitle,WinClass)
gosub movewindow
If WinHeight < 130
gosub movewindow
If WinHeight > %PredefWinHeight%
return
If WinWidth > %PredefWinWidth%
return
This takes care of those pesky wide but short (in height) dialog boxes
that all have the same ahk class and window title as taller and
narrower windows. I have one dialog box in Outlook Express that I
never want to jump, and one I always want to jump, and they both have
the same ahk class and window title. Fooling with
%PredefWinHeight/Width% kept having other consequences, so this seems
to fix it. so far...
-
any updates?
-
I was a little bit behind schedule, but at last got it done. At least apparently, it looks like it's working great!
It now has:
- About Box
- Tray Menu
- Tray Icon
- Executable Icon
- WinBorder, the border around each dialog box, that if the mouse is inside it, it doesn't move the box
- Window Buffer, a buffer that stores the windows that are active, in order not to move already existant windows
Both the border and the buffer use are options in the .ini file, where you can ser "winborder" to the border you'd like the window not to be detected, and UseBuffer to false if you don't like the idea of not having every window being moved.
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
(I'm sory I still don't have a webpage to put all this links, but i hope to have one soon.)
-
Very nice! I'm even using the .ini file now that I understand better how it works.
(I still don't experience any shrinking windows in the applications I use, but the repeated restore/minimize AHK Help test still shrinks that window to a short title bar, after just a handful of click-cycles.)
Thanks!
-
excellent news, unfortunately i won't be able to try it until later tonight.
-
just been testing the new version out and it seems pretty perfect. i think now it's just a case of using it for a few days to see if any other suggestions spring to mind.
i can see that there will possibly always be something that works contrary to what you thought would happen but as 'dialogmove' can't be telepathic i think it's doing a brilliant job now.
i wonder what you think to this 'mode' of operation - specified detectable windows set to always move should be ignored in the buffer?
i guess if there was a configuration box that the user could select various options from instead of editing the ini file would be good - i'm thinking more for people that will be scared away by the thought of editing an ini file.
on a more personal note: if i add extra commands to the script - things like shortcut keys for me to move/minimise/restore/maximise a window - do you think this will be better than running a separate script at the same time. i guess the cpu cycles involved are that minimal between the two options it's a daft question???
anyway, you've done a really fantastic job, jgpaiva. you are my hero.
-
just been testing the new version out and it seems pretty perfect. i think now it's just a case of using it for a few days to see if any other suggestions spring to mind.-nudone
Good to know that! :Thmbsup:
i can see that there will possibly always be something that works contrary to what you thought would happen but as 'dialogmove' can't be telepathic-nudone
Yes, it can't guess, but maybe V10 will ;)
i wonder what you think to this 'mode' of operation - specified detectable windows set to always move should be ignored in the buffer?-nudone
Makes very much sense to me, that's actually a bug, i forgot that. Will fix in the next version.
i guess if there was a configuration box that the user could select various options from instead of editing the ini file would be good - i'm thinking more for people that will be scared away by the thought of editing an ini file.-nudone
It's on the ToDo list, i'm also not a fan of editing .ini files.
on a more personal note: if i add extra commands to the script - things like shortcut keys for me to move/minimise/restore/maximise a window - do you think this will be better than running a separate script at the same time. i guess the cpu cycles involved are that minimal between the two options it's a daft question???-nudone
Running a new script only for that would take you about 4mb of memory. No need for that, you can add the new hotkeys to the end of DialogMove.ahk! :)
-
just a little bug so far: i appear to be getting 'ahk_class #32770' in both the detectablewindows and notdetectablewindows sections in the ini file when i press F9 and F10, i.e. it appears that this is a common way for windows to identify a dialog so it breaking how things work.
emule, confirm shortcut delete, find, and probably a few others i didn't realise share the ahk_class #32770 identifier.
would it be possible for the F9 and F10 shortcut key methods of accepting or blocking dialogs to be done by matching a string in the title bar of the dialog.
i thought this was already catered for in an earlier version but as things have become more complex it looks like it's broken.
otherwise things appear to be working great it's just the ahk_class #32770 that seems to get in the way.
-
Regarding the "ahk_class #32770 bug", i was a bit aware of that. I used that way of detecting windows because it's more unique, and works even when the window doesn't have a title, or even more importantly, when a window has a changing title. (this usually happens in browsers or editors). But since the person can use the "NotDetectableWindows" variable to avoid those situations, i guess i could have it identifying through window name, or some sort of combination of both, or maybe have other 2 hotkeys for adding through ahk_class. I still don't know how to do it, but i'll try to solve it.
I'm now on vacations, which means I can't fix it right now, but you ight expect a new version for next monday or tuesday.
Have a happy easter! :D
-
excellent. enjoy the break.
-
I'm just checking in to say i didn't forget that update, just been a bit busy (with school work (https://www.donationcoder.com/forum/index.php?topic=3239.0)), but i'll get to it as soon as possible. Sorry.
-
no rush, i greatly appreciate all your time spent on the project.
-
Aha! I see that I am getting the shrinking windows activity a bit, only when minimizing/restoring by using a Taskbar button (something I don't do all that often).
Sometimes the window doesn't shrink, but gets moved all the way south on the desktop, with only the titlebar showing above the Taskbar.
Seems like this happened after fewer minimize/restore cycles when I started using the .ini file (before that I commented out any references to the .ini file and put my customizations right in the script).
Don't get me wrong, this is only a minor glitch for me, far outweighed by the usefullness of this utility!
-
Ok.. Just a minor update here. Added visual options and tray menu. The next adition will be costumizable hotkeys/functions, which will allow to have more customization.
As for the "ahk_class #32770 bug", i added a new hotkey (F8), which allows you to add a dialog to the detectablewindows list by window title.
This version is a good improvement, since you can now much more easily edit the options, and more importantly, the windows to move or not.
You can get it in the usual place:
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
-
excellent. i'll try it later tonight. :Thmbsup:
-
just trying the current version - the options window is looking good.
the program seems to be working better than the previous versions - i've not had the shrinking window problem and i've not used the hotkeys to include/exclude windows.
this version does seem to keep forgetting what my screen resolution is - it should be 1920 x 1200 but it keeps reverting back to 1000 x 1000, any ideas????
looking forward to seeing the next version with more options in the settings window...
(unfortunately, i can't use this version as the 1000 x 1000 screen resolution is really messing things up.)
-
Reverting back to 1000x1000? that shouldn't happen, those values don't even make sense. Even so, are you using a multim-monitor configuration?
Even after you change the limits in the options, it changes the values? When you get back to the options menu, they are changed?
-
i'm only using a single monitor - native resolution 1920x1200 (it's a 24" widescreen). i keep changing the numbers from 1000 x 1000 back to 1920 x 1200 - this sometimes works but after a couple of dialogs have been moved or just a minute passes by the settings revert back to 1000 x 1000. i become aware that it's done this because the dialogs don't jump onto the right hand side of the monitor even though that is where my cursor is.
i can't see a pattern (as yet) to what is making the numbers change. i can even put the numbers in, click okay, then open the options window again to check the numbers are still set to 1920 x 1200 and they've changed back to 1000 x 1000.
i've had a look in the .ini file that it creates and i can't see any lines for the resolution size.
when i first run 'dialogmove' it does have the correct 1920 x 1200 numbers, well, it says 1,920 and 1,200 to be precise.
i hope that clarifies things but i appreciate it's not going to help much.
-
i'm running the .ahk script at the moment instead of the compiled .exe and it appears to be working correctly.
the only difference is that i've changed the PredefWinWidth:= from 400 to 500 within the .ahk file - could this have been throwing the .exe version out when changing the related values in the settings dialog?
anyway, it seems to be working perfectly at the moment. :)
-
Maybe it's related to the compiled file.. I'm working in school work right now, but i should have time to look into it later today or tomorrow.
-
i've found the root of the problem: it happens after i click on the 'okay' button in the settings window - this happens in the .ahk file version also.
if, instead, i ignore the 'okay' button and click the 'X' icon in the top right of the settings window then everything works correctly, i.e. the numbers don't change to 1000 x 1000.
-
Ok... Got to it. It was being limited by the arrows on the right of the edit fields (sorry, first time i used those :S).
It's now fixed. I also fixed another bug: it wasn't storing the values of the limits of the screen to the ini file.
Please re-download:
.exe file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk
As this version has more settings in the ini file, please delete it before executing this version.
-
sorry, jgpaiva, but both the new .exe and .ahk still change their settings back to 1000 x 1000 when i click on the 'okay' button.
-
I'm now trying to figure out what could be wrong.
I noticed an error on the stuff i did yesterday (programming late in the night always gets ne into this kind of stuff). It wasn't saving those values to the .ini file correctly.
Please update to the new version, and delete the older .ini files.
Still, this probably isn't the solution, as i can't reproduce the problem here. Not even if i simulate the same resolution you have.
So, i need to ask you: please test this new version, and save the .ini file right when the script is started, and then, right when the script gives the strange error, and please attach it to a post here.
-
i don't think this is going to help you but here goes...
i deleted all versions of 'dialogmove' and made sure that non were running in the background (this is straight after booting up into windows).
i then downloaded the current version of the .exe and .ahk files (using a different download manager - just in case it was caching an old version of 'dialogmove' - can this sort of thing happen? i've no idea).
i then copy both the .ahk and the .exe file into the folder i've made for dialogmove in my 'program files' folder.
i then run the .exe version of dialogmove.
the first .ini file that is created has been included here - named: "DialogMove.exe (first run)"
i then open up the dialogmove settings window and click on the 'general' tab.
i don't change any settings at all.
i then click on the 'okay' button.
i open up the dialogmove settings window again, click the 'general' tab and see that the 'screen top' and 'screen right' numbers have both changed to '1,000'
the .ini file that is created after the above process is included here - named: "DialogMove.exe (after click okay)"
i really hope that helps but looking at the .ini files doesn't appear to give much away (to me at least).
(i get the same results when running the .ahk file instead of the .exe version. if i delete the .ini file and then click to reload the script then everything returns back to normal, i.e. no 1,000 x 1,000 as you'd expect.)
good luck with solving it but i can live without clicking on the 'okay' button.
-
the 'screen top' and 'screen right' numbers have both changed to '1,000'
This happened to me only once. It may have had to do with accidentally reloading the script.
-
Thanks for the big description, nudone. I did the exact same thing you did, and tried using the ini files you sent, but got no similar results.
Still, I made a new version with an atribution made by another way, and maybe that's the solution.
(for those who use ahk, have you ever had problems with doing "var*=2" instead of "var:=2*var"?)
I've very sorry for all the problems, i hope this is the solution.
(You need to use the OK button, since it's the only way to submit the options, or you couldn't change any options..)
-
oh dear. the numbers now change to '0' instead of '1,000' when i click on the 'okay' button.
i'm happy just editing the .ini file if i need to so don't waste time trying to make the 'okay' button work just for me - though, i can appreciate this sort of thing being annoying to you as the author when the code isn't quite perfect.
-
oh dear. the numbers now change to '0' instead of '1,000' when i click on the 'okay' button.
i'm happy just editing the .ini file if i need to so don't waste time trying to make the 'okay' button work just for me
-nudone
Same here :)
-
Ok.. I think it's solved. The bug before this one wasn't my fault, but this one sure was. The only numbers changing to '0' was the "screentop", right? The screenRight was correct (at least, it's supposed to be).
So, please re-download.
.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)
.ahk version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)
-
sorry, jgpaiva, but the new version has exactly the same problem as the previous one for me: both screen top and screen right set to '0' after i click on the 'okay' button.
-
both screen top and screen right set to '0' after i click on the 'okay' button.-nudone
Ok.. At least i know what's NOT in the origin of this problem ;)
I'll continue digging, then.. (https://www.donationcoder.com/forum/esmileys/gen0/Small/THINK.GIF)
-
Ok... Good thing i started looking for the bug elsewhere. I think i might have found it.
I'm really,really sorry to be doing all these updates, but as i can't replicate the problem, this is the only way to know if it's fixed or not. But, this time, i gave it a few tests and i think this might be it.
.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)
.ahk version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)
-
i think this might be it.
-jgpaiva
It didn't pick up my old .ini screen settings, but when I put ithe numbers I wanted in the options boxes, it worked just fine!
I too think this might be it.
Thanks!!!
-
(..)it worked just fine!
I too think this might be it.
-AndyM
You can't imagine how happy that makes me! :D
How about you, nudone?
-
jgpaiva,
Once you are sure the Options dialogs are working ok, you might (or
might not ;) ) want to consider putting in an option labeled "Move any
window under this height, unless it's specifically listed as a window
to not move".
In my case I would select this option and put 140 in the option box.
I've been adding the code below to the .ahk script.
I started doing this because I had two dialog boxes with the same
window name and class, one big and the other wide but not tall. I
didn't want to move the first and always wanted to move the second.
This option not only worked for this scenario, but it takes care of
those pesky wide (wider than %PredefWinWidth%) but short in height
windows. When I click a red x, even the wide "are you sure you want
to exit without saving?" boxes jump right to my cursor.
If you think this option would be too confusing, no problemo. It's a
matter of seconds for me to paste these two lines into the code.
Andy
WinGetPos,WinX,WinY, WinWidth, WinHeight,ahk_id %ActiveWindow%
if WinWidth =
return
WinGetClass,WinClass
WinGetTitle,WinTitle,ahk_id %ActiveWindow%
WinClass=ahk_class%A_space%%Winclass%
If NotDetectableWindow(WinTitle,WinClass)
return
If DetectableWindow(WinTitle,WinClass)
gosub movewindow
If WinHeight < 140 ;I added
gosub movewindow ;I added
If WinHeight > %PredefWinHeight%
return
If WinWidth > %PredefWinWidth%
return
-
I think i understand your idea, Andy, it makes some sense to me.
In the next version, i'll be adding the costumizable hotkeys, and you'll be able to set a hotkey to a predefined action. I think i'll use that same system to have a "rules" system.
I'm not sure if i can do it, but it'd be great to be able to add a rules system, where the user could redefine what windows should be moved, based on those rules.
And example of a rule could be:
WindowHeight > 200 AND WindowHeight < 300 OR WindowHeight > 400
If this isn't possible, i'll add the option you mentioned ;)
-
... I'm not sure if i can do it, but it'd be great to be able to add a rules system, where the user could redefine what windows should be moved, based on those rules.
And example of a rule could be:
WindowHeight > 200 AND WindowHeight < 300 OR WindowHeight > 400
-jgpaiva
This would be very cool!
-
very sorry, but the latest versions, .exe and .ahk still have the same problem when i click on the 'okay' button. that's from a clean start up with no .ini files lying around anywhere.
AndyM's solution to the short but wide dialogue box is something that i would like to see in the final version (if the rules options don't work out) as these are the type of dialog boxes that first annoyed me (i think i might have made a request earlier that this sort of dialog could be treated as a special case). you could almost trap the majority of annoying dialog windows just by stating that they have to be less than a certain short height - that's how my original ahk script tried to cover everything with just a bit of code. little did i realise just how complex this coding snack was to become.
i'm now going to attempt the AndyM cut down version of DialogMove with just the 'WinHeight < 140' method in place and almost all the other code chopped out - maybe this way lies folly.
-
well, i'm sure you'll be absolutely staggered at the advanced coding level i'm working at, here's the "nudone's AndyM's jgpaiva's DialogMove Remix"
WinGetPos,WinX,WinY, WinWidth, WinHeight,ahk_id %ActiveWindow%
if WinWidth =
return
WinGetClass,WinClass
WinGetTitle,WinTitle,ahk_id %ActiveWindow%
WinClass=ahk_class%A_space%%Winclass%
If NotDetectableWindow(WinTitle,WinClass)
return
If DetectableWindow(WinTitle,WinClass)
gosub movewindow
If WinHeight < 150 ;AndyM
gosub movewindow ;AndyM
If WinHeight > 151 ;nudone
return ;nudone
;If WinHeight > %PredefWinHeight%
; return
;If WinWidth > %PredefWinWidth%
; return
-
very sorry, but the latest versions, .exe and .ahk still have the same problem when i click on the 'okay' button. that's from a clean start up with no .ini files lying around anywhere.
-nudone
Ah, I just checked mine, and when I first opened the Options dialog, the readings were correct (1024 Screen Top, 1280 Screen Right). Then I clicked ok, and when I triggered the script, the small dialog box didn't move as expected. Opened up the Options dialog and the Screen Top and Screen Right were both set to zero (the other settings were still correct). I input 1024 and 1280, clicked OK, and everthing worked fine. Opened the Options dialog to look, and the numbers were correct. Cancelled the Options, and everything is still ok. Fwiw, I think the only place I'm seeing this behavior is it the two fields, Sreen Top and Screen Right.
So the error seems to sort of toggle. Or maybe things work right after you've made a change and then clicked "ok", but not work right if you click "ok" after making no change. Or maybe something else...
-
okay, my 'remix' isn't worth spinning.
i now see that's it's a bit too dumb in how it works. there are a few dialog windows that i have gotten used to auto jumping to the cursor that the above method prevents from working.
just the AndyM original remix is sufficient for the short annoying dialogs.
-
If WinHeight > 151 ;nudone
return ;nudone
;If WinHeight > %PredefWinHeight%
; return
;If WinWidth > %PredefWinWidth%
; return
-nudone
Doesn't this bypass the %PredefWinHeight% and %PredefWinWidth% parameters and not move any boxes over 151 high unless they've been specifically added to the Detectable list?
I like having non-specified boxes under 450 high or 400 wide (my settings) be moved. (Plus I like having non-specified boxes under 140 high moved no matter how wide they are :))
-
Oops, nudone, you already figured this out and posted your reply.
I need to type faster!
-
Ok.. It looks like the bug is related to the damn arrows in the edit boxes. I'm going to lose those, and let's see what we get.
Please re-download:
.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)
.ahk version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)
-
It's working for me. I tried to break it but couldn't.
-
well done, jgpaiva, that has certainly cured the 'okay' button click problem for me. thanks.
-
Hey Nudone,
Alternative cure for you, not quite what you want but it does a good job. Teleport Cursor by Jason Hood XD auto jumps your cursor to the default button in that dialog only downside is if you click accidentally and the default isnt what you want :(, hopefully you get something that works perfectly for you
http://www.geocities.com/jadoxa/telecurs/index.html
-
... auto jumps your cursor to the default button in that dialog ...
-SexyLilDarkPaw
There's a setting in the OS (XP) that does that. What's slick about DialogMove is that the dialog box jumps to the cursor, so after clicking a dialog box button, you don't have to move the cursor back to where it was originally. Much handier than one might think.
-
Hey Nudone,
Alternative cure for you, not quite what you want but it does a good job. Teleport Cursor by Jason Hood XD auto jumps your cursor to the default button in that dialog only downside is if you click accidentally and the default isnt what you want :(, hopefully you get something that works perfectly for you
http://www.geocities.com/jadoxa/telecurs/index.html
-SexyLilDarkPaw
thanks for making the suggestion but that method is exactly what i don't like.
-
Ok... An incomplete update (see it like a beta ;) )
I just want your opinion on the direction i'm heading:
(only the .ahk version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk) was updated)
-
I just want your opinion on the direction i'm heading:
-jgpaiva
Looks good to me! The extra set of Height and Width rules allow me to move all wide but short windows, so I don't have to add lines to the script.
I haven't been using Hotkeys or the buffer, so I can't comment on those.
I think you might have your height and width labels reversed in the Options Dialog.
-
Ooops! :-[ :-[
Yes, all the labels were wrong, the height was switched with the width ;)
It's fixed now.
I'll be completing this update soon, because nothing is centered, etc...
.ahk version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)
-
I still think the first set of Width and Height rules are reversed, but the second is ok.
-
Right.. I did fix it, but didn't upload to the ftp. Sorry. It's there now.
.ahk version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)
-
Right.. I did fix it, but didn't upload to the ftp.
.ahk version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)
-jgpaiva
Which I would have easily seen had I checked the handy version number...
-
Which I would have easily seen had I checked the handy version number...
-AndyM
Oh... So THAT's what version numbers are for? eheh... Now i get the importance of it ;)
-
great work, jgpaiva.
just a quick question: in the shortcut keys config section, do i put...
#F9
instead of 'F9' if i want to use the 'windows' key and the 'F9' key at the same time.
single keys for shortcuts tend to get confused with other programs from my experience - and many double key shortcuts are already taken up (adobe, etc) except for 'windows' key combinations.
i suppose i ought to test what i'm asking in my question - i'll do it in a minute after i've clicked 'post'.
edit:
tested and working.
fantastic. feels like a 'real' program now. :Thmbsup:
-
i know 'gridmove' is kind of more important at the moment but i'd just like to suggest a slight change for 'dialogmove' if you can, jgpaiva...
when the dialog window pops up and is moved to the cursor positions - currently the window is centered across height and width under the mosuer cursor (as expected).
could it be changed (with the option to turn the feature on and off by the user) so that the dialog window moves to a position so that the highlighted or 'in focus' button on the dialog box is directly under the mouse cursor - this is still with the exception of the dialog window moving off the edge of the screen.
i see the difficulty in this method as sometimes there doesn't appear to be an 'in focus' button on some dialog windows (maybe there is a button in focus but it just doesn't look like it is on my screen).
maybe it's a bad idea - depends on what problems it would lead to - but at the moment it's just something that kind of seems obvious to me that 'dialogmove' ought to do -perhaps i'm just becoming even more lazy so just moving the mouse cursor a few pixels now seems like a major effort.
other than that i have to say that 'dialogmove' has become a very natural part of my windows operating system. i'm still amazed when windows jump to my cursor - i still automatically start to move my cursor to the center of the screen in preparation to click on some dialog windows before they appear - but 'dialogmove' beats me to it which is great.
-
Actually, that makes more sense, it'd be exactly like the "cursor jump to dialog" but it's "dialog jump to cursor". I've been through ahk's functions, and this should be fairly easy to implement. :Thmbsup:
-
fantastic. i look forward to seeing the result.
-
i look forward to seeing the result.
me too
-
not wishing to rush you, jgpaiva, but here are a few more suggestions - one of which might seem like heresy.
i'd still very much like to see the dialog window move so that it came to rest with the highlighted button under the mouse cursor, but i think that some windows don't have a highlighted button - well, it looks like that to me - maybe they are 'in focus' but they just aren't 'highlighted'. anyway, if it's true that some dialog windows don't have a highlighted button could you make it so that dialogmove looks for the 'okay' or 'yes' or 'save' button instead.
and here's the heretical idea. how about if dialogmove worked exactly as it does now and then the mouse cursor jumped the final couple of inches to the highlighted button? i admit i've not really thought about this suggestion so it might just be a really annoying method to use.
as always, if you can make these features user selectable it would be greatly appreciated.
thanks.
-
i feel bad about suggesting more but i thought this might be interesting - possibly pointless.
it's only a cosmetic thing anyway.
instead of the dialog window 'jumping' to the mouse cursor position, how about the dialog window was seen to move to the cursor position, i.e. there was a little bit of animation involved - say one or two steps that the window would travel along a path until it landed under the cursor.
i can imagine this looking quite nice if it was smooth enough but it would probably look horrible if it was too jerky.
-
instead of the dialog window 'jumping' to the mouse cursor position, how about the dialog window was seen to move to the cursor position, i.e. there was a little bit of animation involved - say one or two steps that the window would travel along a path until it landed under the cursor.
i can imagine this looking quite nice if it was smooth enough but it would probably look horrible if it was too jerky.
-nudone
Myself, I kinda like the instantaneous automagical appearance of the dialog box under my cursor. Even months later an occasional "damn that's neat" still comes out.
-
i agree - as that is really the point of dialogmove.
i only thought about the animated move idea as i have one or two windows that appear in the center of the screen AND then jump to the cursor position. most of the time the dialog window appears directly under the cursor without first appearing in the center of the screen.
it's the very few times that the dialog window appears in the center first and then jumps that looks a bit odd - i just thought it might be a bit more pleasing on the eye if in these cases the dialog travelled across the screen instead of jumped.
it is a very small annoyance and i wouldn't expect jgpaiva to consider it seriously unless he was very bored and seeking a problem to solve. well, if jgpaiva thinks it's a bad idea anyway then i'd be happy to forget about it.
the previous suggestion of dialog jumping so that highlighted button rests under cursor is really what i'd like to see implemented.
-
the previous suggestion of dialog jumping so that highlighted button rests under cursor is really what i'd like to see implemented.
That would be especially slick.
-
i agree - as that is really the point of dialogmove.
i only thought about the animated move idea as i have one or two windows that appear in the center of the screen AND then jump to the cursor position. most of the time the dialog window appears directly under the cursor without first appearing in the center of the screen.
it's the very few times that the dialog window appears in the center first and then jumps that looks a bit odd - i just thought it might be a bit more pleasing on the eye if in these cases the dialog travelled across the screen instead of jumped.
-nudone
Unfortunatelly, there's no way to solve that :(
Dialogmove moves all windows as fast as it can, which means that somethimes the user doesn't see it coming up and other times it does. (but it comes up always in the center, only then it's moved). The script itself doesn't have any idea if the window appeared to the user or not, so i cannot make it behave differently in those cases.. Sorry
As for your other request, i'm right now working on it!
-
excellent.
-
As for your other request, i'm right now working on it!
-jgpaiva
That's great news.
btw, I've been periodically getting the "window shrinks to very short Titlebar" syndrome. It seems to happen sometimes when I close a dialog box which was moved properly, and then the focus goes to the next open window. That window shrinks, and because it is small, it then jumps to the cursor. Once in a while, an unshrunk window that gains focus will jump to the cursor. None of it happens often enough to make me even think about not using DialogMove. I'm 95% positive in all cases it only happens when I close a moved Dialog box.
-
i've not encountered anything like that for a long long time. strange.
-
I'm running more AHK scripts than I used to, 8 including DialogMove. I wonder if that has anything to do with it.
-
cody has a lot of credits waiting for you, jgpaiva - if you can implement the 'intelligent' position dialog to place highlighted button under mouse cursor.
i love dialogmove more and more each day - especially when i have to use someone else's retarded machine that doesn't have dialogmove on it.
-
cody has a lot of credits waiting for you, jgpaiva - if you can implement the 'intelligent' position dialog to place highlighted button under mouse cursor.
-nudone
Oh... Sorry, actually, it's already done and working, but no config yet. I'll try to upload it still today.
i love dialogmove more and more each day - especially when i have to use someone else's retarded machine that doesn't have dialogmove on it.
-nudone
;D ;D ;D ;D
-
great, looking forward to downloading it.
-
Ok... Sorry for the delay.
It's here, dialogmove 1.8.9.
Added the "move to active button" option. (if there isn't an active control, it acts as it did before).
DialogMove v1.8.9 updated 09-10-06:
moves windows smaler than a given size to a place closer to the mouse position.
[Forum Topic (https://www.donationcoder.com/forum/index.php?topic=3097.0)] [.ahk Version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)] [.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)] [About Box (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMoveAbout.png)]
-
heh, heh, heh, brilliant.
i think it's the ultimate improvement.
great work, jgpaiva.
-
heh, heh, heh, brilliant.
i think it's the ultimate improvement.
great work, jgpaiva.
-nudone
It sure is!
Even i like it, and i don't use dialogmove (things moving by themselves on my screen without me telling them to confuses me :S)
It was definitelly a good idea! :Thmbsup:
Glad you like it ;)
-
Very nice, thanks!
-
here's just a suggestion for when you have nothing better to do one day, jgpaiva.
i really like the new move dialog so that highlighted button move to cursor type thing, but there are times when it would be nice for a different button to act as the target.
i use flashget and the 'save' dialog that opens has the save location highlighted rather than just the 'okay' or 'save' button.
my suggestion is that it would be nice/useful if the user could make 'dialogmove' learn how you want it to behave with certain windows. just like it works at the moment how you can specify whether a window should be ignored or always moved by pressing one of the hotkeys - it would be handy so that you could press a hotkey so that dialogmove knew which button it should use as the target to move the mouse cursor with specific dialog windows.
i hope that makes sense, and i hope it sounds like a worthwhile feature to add.
-
I know... It seems unbelievable, but.. There's a new version of DialogMove!! Run to get it ;)
I've updated it to give it some more speed when moving the windows, and to remove the screen configuration options, the script gets those by itself, no need for configuration.
DialogMove v1.8.93 updated 10-12-06:
moves windows smaler than a given size to a place closer to the mouse position.
[Forum Topic (https://www.donationcoder.com/forum/index.php?topic=3097.0)] [.ahk Version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)] [.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)] [About Box (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMoveAbout.png)]
[edit] Thanks nudone... LoL, i'm so messed up that i even mix my own stuff ;) [/edit]
-
fantastic - but don't you mean you've updated DIALOG MOVE not gridmove. :D
will now download.
-
DialogMove v1.8.93 updated 10-12-06:
-jgpaiva
The occasional problem that I was having where a window jumped that wasn't supposed to, either shrinking or not, seems to have gone away.
Do you thing the revised code (which I didn't really look over) is responsible?
-
The occasional problem that I was having where a window jumped that wasn't supposed to, either shrinking or not, seems to have gone away.
Do you thing the revised code (which I didn't really look over) is responsible?
-AndyM
Well... That's good! :D
I don't think the few lines i added to the code could make any difference. On the other hand, this new version was compiled with a way newer version of AHK, which means that might have been a bug in the ahk code that has already been fixed. (i haven't noticed it in the changelogs, though..)
But anyways, it's good to know it's gone now :D
-
You think DialogMove was smart? Well.. It got smarter.
Now with auto-detection of buttons' names.
The window focus will be set on buttons named "save", "ok" (and the similar ones in portuguese, so that i could test it ;)).
Notice that this will work regardless if there are any other focused controls. If these exist, they'll be beneath your mouse.
Other names of controls to look for are welcome.
(if these controls are not present, it'll move to the active control. if there's no active control, it'll move to the middle of the window)
DialogMove v1.8.97 updated 21-01-07:
moves windows smaler than a given size to a place closer to the mouse position.
[Forum Topic (https://www.donationcoder.com/forum/index.php?topic=3097.0)] [.ahk Version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)] [.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)] [About Box (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMoveAbout.png)]
PS: this was a first atempt, to see how it works out. If it doesn't work out, i'll have to think of a way of configuring it per window. I've just been having some trouble figuring out how to do it.
-
New update:
Added configuration of which controls to look for. You can find those under the "rules" tab in the settings. (notice that it is just a comma-separated list of the words that have to be in the text of the controls to look for)
DialogMove v1.8.98 updated 21-01-07:
moves windows smaler than a given size to a place closer to the mouse position.
[Forum Topic (https://www.donationcoder.com/forum/index.php?topic=3097.0)] [.ahk Version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)] [.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)] [About Box (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMoveAbout.png)]
-
fantastic. christmas has come very early for me this year. very, very early it seems.
i'll have to try this tomorrow but i'm overjoyed that you've done this update.
-
i think the new version is working perfectly. seems to know what's going on with larger windows a bit better too.
-
i think the new version is working perfectly. seems to know what's going on with larger windows a bit better too.
-nudone
I'm very happy to hear that!! :D
If you find anything you'd like to add, don't existate to post ;)
-
So far so good.
Thanks jgpaiva!
-
i haven't thought for too long about this so i may be talking complete rubbish:
i'm wondering if the rules for matching smaller window sizes before moving the dialog is actually superfluous to making dialogmove work.
now that the rules are there to move windows depending on their 'in focus' button (okay, save, cancel, etc) it looks to me that is all that is required, i.e. no need to look for size.
as the windows that are moved by dialogmove tend to have the types of buttons mentioned above then perhaps we could try a version that abandoned the size method.
i mention this as there are still a few windows that don't behave as they should. sometimes they move, sometimes they don't. making a specific window NOT move often effects another window not moving also. these are slight issues but i'm wondering if the size function is the one that is getting in the way.
i need to experiment for a bit and then i'll report back.
-
Sorry nudone, but i didn't exactly understand what you meant.
Please give me some examples, so that i can better understand the problem :)
-
well, the main problem seems to be with the 'save as' dialog. that's the one that troubles me.
i've specified for it to be moved by dialogname 'Save As', sometimes it moves, sometimes it doesn't i can't see any pattern to the problem. i admit it's larger than the rules i've set for size which are 1920 x 200 but as it moves sometimes i just wonder why it doesn't move all the time.
i shall try to follow exactly what is happening when i use the machine tomorrow and then i'll try and give a detailed report.
-
Notice that dialogmove is made so that this new addition doesn't actually tell the window to move, it only tells it where to move, if it is moved.
Also, while testing this, i found this:
Remember that dialogmove doesn't move windows if they'll appear beneath the mouse. A save box is quite big, so there's a good probability this will happen. Please confirm if that's the reason it doesn't move sometimes and others it does.
-
i wondered if it was the 'don't move the window if it's already under the mouse' feature but it's not that.
i'm wondering if it's something to do with the list of name that i had in the 'move these windows' box. when there is only 'Save As' in the list of windows to move it appears to work okay. as soon as others are added to the list then it becomes a bit random.
i really haven't tested it enough yet to spot what's happening so when i say it works when there is only 'Save As' in the 'move this window' section then i could well be very wrong.
i shall try changing a few rules for size matching and see what happens.
(i'm about ready to fetch my big lump hammer out of the shed in a minute and smash the computer up into little pieces - it's being naughty again and i really have about lost my patience with it. i'm trying to think of what life i can live without ever having to turn a computer on again.)
-
Is it possible to exclude the window that pops up when I press alt-tab (in Vista)? Hotkeys don't seem to be able to catch it.
Thanks,
Eric
-
Is it possible to exclude the window that pops up when I press alt-tab (in Vista)? Hotkeys don't seem to be able to catch it.
Thanks,
Eric
-ayryq
i had the same problem. i don't think there is a solution other than using a different alt-tab program.
i'm using TaskSwitchXP http://www.ntwind.com/software/taskswitchxp.html so the standard alt-tab window nolonger appears. also, i think the standard vista alt-tab box is very annoying - it's very difficult to differentiate the icons and thumbnails.
if you do use TaskSwitchXP, you'll probably have to get the settings just right to make the most of it. if so, just ask and i'll go through the settings i'm using.
edit:
i probably should post my setting for dialogmove too. i don't think the default rules are quite right for the most enjoyable use.
-
for those of us not in the know,
could you describe briefly - or link to a description of what this programme does? (& how it does it?)
JG has no home page for his apps but I know he's a busy man too... :)
-
for those of us not in the know,
could you describe briefly - or link to a description of what this programme does? (& how it does it?)-tomos
you can check out the link in jgpaiva's sig, which leads to this page (https://www.donationcoder.com/forum/index.php?topic=3461) and also here's the about box which also might help explaining about this program.
(http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMoveAbout.png)
-
Somewhat off-topic:
In the about box (above), there should not be a comma in the first sentence. Also, the word "customizable" is spelled "costumizable," the comma there should be a semicolon (";"), "informations" needs to drop the "s," the last "it's" should be "its," and there should be a "the" after "at" and before "donationcoder.com"
Fixed version:
Spoiler
This is a small script that moves small dialog windows to the mouse position as soon as they are created. It's highly customizable; for more information on how it works, please see its topic at the DonationCoder.com forums.
I'm picky about that kind of stuff, so I thought I'd point it out... :P
</offtopic>
-
i believe jgpaiva is aware of the omissions and what-not but he seems mighty busy nowadays. it must be the finals at school.
-
for those of us not in the know,
could you describe briefly - or link to a description of what this programme does? (& how it does it?)
JG has no home page for his apps but I know he's a busy man too... :)
-tomos
i'll try and get a screencast done of this program as i think it's undervalued. honestly, one day all operating systems will use this same dialogmove method - unless they're using a small screen.
-
thanks - I guess the name says it all anyway - I'll try it out!
-
i'll try and get a screencast done of this program as i think it's undervalued. honestly, one day all operating systems will use this same dialogmove method - unless they're using a small screen.-nudone
screencast is a great way to promote the program and create awareness of its usage.. :up:
-
i've been looking at what would best demonstrate 'dialogmove' when recorded in a screencast - and now i'm wondering if i'm losing my mind.
i thought i'd turn dialogmove off and record how things are without it, which would then make a good comparison with a second recording with dialogmove enabled; a before and after type of thing. the problem is, i can only find one regular dialog window that gets moved by dialogmove - all the others i thought were being moved by the util are actually just moved by vista by default: things like save and open dialog windows.
there are occasions when vista doesn't move the dialog; which dialogmove must then be catching - otherwise i would have noticed this non moving behaviour sooner. when i say vista, i mean the programs i'm using really.
now that i've looked at what i'm doing it seems that there are very few dialog boxes in vista that are annoying enough to need regularly moving. so far i can only find the 'do you want to empy the recycle bin' dialog. vista just doesn't seem to throw up many small dialog boxes.
so, what i'm trying to say is, until i can find more dialogs that need moving i can't justify doing the screencast. i'm even doubting the use of dialogmove now. i can't understand it. there must have been lots more annoying little dialogs in xp - or maybe the save/open dialogs didn't behave as well as they do in vista. maybe it was just the programs i was using back then on xp.
i shall investigate and make a list of annoying dialog windows that popup in vista over the next few days.
-
I couldn't live without DialogMove (using XP SP3).
I started using DialogMove just before or just after I upgraded to SP2, and before that none of the dialogs moved. The best I could do was use the XP setting to move the cursor to the dialog box, an inferior approach.
I didn't know Vista duplicates some of the functionality of DialogMove, but using XP I find DialogMove essential for convenience.
-
excellent. i'm glad it's not just me that appeciates the benefits of dialogmove.
as for vista. it's more a case of when using something like notepad the open/save dialog windows do try to open up close to where you want them, i.e. near the 'file' menu. it definitely doesn't do it correctly everytime - sometimes it just remembers the position of the dialog when it last appeared - which could be at the opposite side of the screen. meaing 'dialogmove' would have corrected it if it was enabled.
i'm compiling my list anyway. i've got four annoying dialog boxes on it so far. the quest continues.
-
well, it's certainly useful for xp
-
a word of warning to anyone trying it out for the first time - it has hotkeys on by default -
so it steals the F8 through to F11 keys from all apps
-
good point, tomos. i always switch the hotkeys to include the winkey.
maybe a few of us can list what we think is worth mentioning to newcomers of dialogmove and i'll try to include them in the screencast(s).
i currently have about nine annoying dialog windows in my list that pop up on my vista system, a few more and i'll make the screencast.
UAC in vista also seems to prevent dialogmove from saving changes made in the options panel - i have a work around for that (i believe without disabling UAC) so i'll include that in the screencast too.
-
I disable the hotkeys and add the occasional dialog box manually.
Once or twice I've used the hotkeys when I knew I'd have a number dialog boxes to add.
-
more starting up stuff :)
how do I exclude a particular popup window or is that possible?
it's from Filehamster -
it popups a notification that it's making a revision and I dont want it going to where the mouse is
Would it be one of the shortcut options:
> MakeNotDetectable
> MakeNotDetectableTitle
thanks for any help ;)
-
is that a suggestion for the screencast or are you stuck with that problem, tomos?
if you are stuck, then yes, you'd try one of the shortuts - though, i can't remember now if some windows just won't behave.
-
Well I enabled the shortcuts and clicked the one for
> MakeNotDetectableTitle
when the popup window was visible (& presumably had focus) and it's remained in it's corner since (good window!)
Re changing the shortcuts - it's difficult to know what works without doing a big experiment - I mean to say:-
I dont know how to type in e.g. Control key or Windows key - do you think should I use the Autohotkey shorthand for the different keys ?
thanks!
-
Well I enabled the shortcuts and clicked the one for
> MakeNotDetectableTitle
when the popup window was visible (& presumably had focus) and it's remained in it's corner since (good window!)
-tomos
that is the correct procedure. if that doesn't work - because the title isn't recognised you can then try just MakeNotDetectble (without title).
the shortcuts for the hotkeys are the same as autohotkey's so:
# is winkey
! is alt
+ is shift
^ is control
eg. you want to use the winkey plus F11 to initiate MakeNotDetecableTitle, so you put the following into the dialogmove options:
#F11
or if you prefer...
[ You are not allowed to view attachments ]
-
i'm about ready to make the screencast. anyone want to add anything that they think i should mention.
i notice that the .exe version of dialogmove gets picked out as a virus (false positivie autohotkey again), but it looks like the script version isn't detected. has anyone had issues with this - i could recomment do use the script version in the screencast.
-
i'm about ready to make the screencast. anyone want to add anything that they think i should mention.
-nudone
no actually :)
I just wanted to say that I've been using it since (the script version), using AXEM to start it with windows along with a few other scripts - no problems, happy user :up:
-
screencast postponed again. the dialogmove icon isn't appearing in my system tray when i run the .exe version - well, sometimes it appears and sometimes it doesn't (it isn't hidden).
maybe i'll just have to go back to using the script version.
-
is there a way of running AXEM silently?
it looks like i can run AXEM as admin (on vista) and then DialogMove will be able to work properly with UAC enabled.
(i can't run the script directly with admin privileges - only appears to work with .exe files.)
-
is there a way of running AXEM silently?
-nudone
"silently"- do you mean that it wouldnt show a window when started? You'd probably have to ask Justice in the AXEM thread, I dont know of a way.
-
yeah, so AXEM doesn't show itself - I'd only need to to start DialogMove and nothing else.
at the moment, FINGERS CROSSED, the .exe version is working okay with my anti-virus (avira). i've simply changed the name of the dialogmove .exe file so Avira doesn't recognise it - i'm assuming it was just picking the name out it's database.
-
(this is just a suggestion for if/when jgpaiva has time to update dialogmove - i know he's very busy at the moment.)
in addition to the hotkeys that allow you to make dialogmove remember a window, it would be nice if there was an option to do something similar by using the mouse, i.e. a right click context menu would be perfect.
example:
1. a dialog window opens - it's one that doesn't fit within the rules you've set for dialogmove (or it does fit within the rules but you don't want this particular window to move).
2. you right click on this dialog window's title bar (if it has one) and then from the context menu that would appear, you have the four choices that relate to the current hotkeys.
3. you then select from the menu the action you want the window to perform...
- make detectable by title
- make detectable
- make NOT detectable by title
- make NOT detectable
i think this would be a really nice feature.
-
<<Off topic>> Nudone, I just spotted a Cody duck in your Icon/Avatar! What's with that. Is there a prize? Sneaky but fun! 8)
-
<<Off topic>> Nudone, I just spotted a Cody duck in your Icon/Avatar! What's with that. Is there a prize? Sneaky but fun! 8)
-SleepingWolf
well spotted, but I have no control over Cody, he comes and goes as he pleases. if you explain to mouser where you saw Cody he well have a prize for you (or maybe just seeing Cody is a prize in itself).
-
hum it is normal that my avira antivirus detect a virus in the exe file??
-
:( :( It's the usual false positives with authotkey (the language used to build GridMove).
To make sure, you can try uploading the file to Virus Total (http://www.virustotal.com/), which checks it using a few a few antivirus.
Unfortunately, this is caused by incompetent anti-virus designers, and there isn't anything a developer can do to prevent this problem.
-
It's incredible!
After 3 years of no updates, here's dialogMove 2.0!
It's so good that we jumped past 1.9 :P
Actually, it's pretty much the same, except that now it works on multiple screens!
Go get it right away :P
DialogMove v2.0 updated 24-04-10:
moves windows smaler than a given size to a place closer to the mouse position.
[Forum Topic (https://www.donationcoder.com/forum/index.php?topic=3097.0)] [.ahk Version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.ahk)] [.exe version (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMove.exe)] [About Box (http://jgpaiva.dcmembers.com/CS/DialogMove/DialogMoveAbout.png)]
-
Actually, it's pretty much the same, except that now it works on multiple screens!
If I don't have multiple screens, should I stick with the old version?
-
Rule #1 of free software... the newest version is best. (Assuming its a standalone... if its a
multi-module project, be careful, but this isn't)
-
AndyM: has it been working well for you? Then it probably won't make any difference.
I also corrected a few lines of code that looked like a bug, but if you haven't noticed it, then probably this update will be pretty much the same :)
SingingBoyo: actually, I'd say that with free software, if what you have now is working, you probably don't want to update: the developer might have introduced new bugs :P
-
It has been working well, for a long time. Once it a while it still does something odd, usually moving a window that shouldn't have moved (too big).
If that sort of thing happens again, I'll try the new code. Might anyway.
-
(just pm'ed you, jgpaiva.)
i'll be giving this 2.0 version a great deal of testing when i get back to my multi-screen setup. i am so excited about this.
whilst i had a dual screen setup it didn't seem so crucial to have DialogMove working on both screens - but now i've gone to the multi-screen setup (4 screens), having DialogMove work on all screens is going to be absolutely fantastic - it really, really, is going to make a difference to my day.
thanks for spending time on this, jgpaiva.
-
SingingBoyo: actually, I'd say that with free software, if what you have now is working, you probably don't want to update: the developer might have introduced new bugs :P
-jgpaiva
What, is this a beta version? Or worse, alpha? Just deal with the bugs now, then you can get the developer to fix them before you actually NEED the new features :P
-
No, this is supposed to be a full version (unless I was using that irrational numbering scheme of KDE where the 'X.0' versions mean beta/alpha).
But with free software (to be fair, with ALL software - free software only suffers more from this syndrome because it doesn't have such extensive testing), you really never know if the developer didn't add a few more bugs to the code when fixing others :)
-
excellent. the new DialogMove appears to be working perfectly. I've not used it for long but all dialog windows behave as expected so far.
thank you very much for this, jgpaiva. my machine feels 1000% friendlier already.
-
Cool nudone, glad to know it's working for you ;)
-
I found this little gem yesterday and have found a couple of issues.
The "which windows..." entry in the options allows newlines but doesn't interpret them as separators, with the effect that the ini can get populated with entries that can't be interpreted. It's not clear what the separator should be, either.
Trivial: on the "rules" tab, "Height" is misspelled.
-
Hi Oblivion!
Try using a coma (","), it should work. If it doesn't, just select the window you want to make detectable and press F8.
-
Hi Oblivion!
Try using a coma (","), it should work.-jgpaiva
Aha. I was experimenting with semicolons. Thanks!