Author Topic: IDEA: move small dialog windows to cursor position (Read 174461 times)

jgpaiva · « **Reply #25 on:** April 08, 2006, 07:08 PM »

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!

(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.dcmem...gMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...gMove/DialogMove.ahk

AndyM · « **Reply #26 on:** April 08, 2006, 10:32 PM »

I have 5 windows I don't want to move, so I had added:

[Select]

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

jgpaiva · « **Reply #27 on:** April 09, 2006, 03:59 AM »

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:

[Select]

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:

[Select]

DetectableWindows=
NotDetectableWindows=Online§Calculator§Volume Control§ahk_class TformStopwatchFloatingForm§ahk_class TformClockFloatingForm

Don't forget to get the new version (.exe file: http://jgpaiva.dcmem...gMove/DialogMove.exe .ahk file: http://jgpaiva.dcmem...gMove/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

nudone · « **Reply #28 on:** April 09, 2006, 06:30 AM »

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.

jgpaiva · « **Reply #29 on:** April 09, 2006, 06:38 AM »

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 (April 09, 2006, 06:30 AM)

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 (April 09, 2006, 06:30 AM)

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...

nudone · « **Reply #30 on:** April 09, 2006, 06:50 AM »

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.

nudone · « **Reply #31 on:** April 09, 2006, 07:28 AM »

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.

jgpaiva · « **Reply #32 on:** April 09, 2006, 07:34 AM »

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 (April 09, 2006, 07:28 AM)

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 (April 09, 2006, 07:28 AM)

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?

)

nudone · « **Reply #33 on:** April 09, 2006, 08:17 AM »

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?

AndyM · « **Reply #34 on:** April 09, 2006, 10:55 AM »

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).

nudone · « **Reply #35 on:** April 09, 2006, 11:57 AM »

Btw, I've never had the shrinking window problem you and nudone have experienced (running XP Pro, SP2).

-AndyM (April 09, 2006, 10:55 AM)

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.

AndyM · « **Reply #36 on:** April 09, 2006, 12:07 PM »

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 (April 09, 2006, 11:57 AM)

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).

jgpaiva · « **Reply #37 on:** April 10, 2006, 03:35 AM »

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 (April 09, 2006, 08:17 AM)

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:

[Select]

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.dcmem...gMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...gMove/DialogMove.ahk

nudone · « **Reply #38 on:** April 10, 2006, 11:39 AM »

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.

AndyM · « **Reply #39 on:** April 10, 2006, 11:49 AM »

[Select]
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 (April 10, 2006, 03:35 AM)

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

jgpaiva · « **Reply #40 on:** April 10, 2006, 12:00 PM »

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 (April 10, 2006, 11:39 AM)

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

)

nudone · « **Reply #41 on:** April 10, 2006, 12:03 PM »

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 (April 10, 2006, 12:00 PM)

let the revolution begin...

jgpaiva · « **Reply #42 on:** April 10, 2006, 04:34 PM »

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.dcmem...gMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...gMove/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]

nudone · « **Reply #43 on:** April 10, 2006, 05:02 PM »

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.

nudone · « **Reply #44 on:** April 10, 2006, 05:26 PM »

is that last version working correctly, i'm finding that it's moving every window i open not just the small ones.

jgpaiva · « **Reply #45 on:** April 10, 2006, 05:40 PM »

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.dcmem...gMove/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...gMove/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]

nudone · « **Reply #46 on:** April 10, 2006, 05:44 PM »

great. i know you can do it, jppaiva.

nudone · « **Reply #47 on:** April 10, 2006, 06:01 PM »

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.dcmem...om/CS/DialogMove.exe
.ahk file: http://jgpaiva.dcmem...om/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 (April 10, 2006, 05:40 PM)

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.

jgpaiva · « **Reply #48 on:** April 10, 2006, 06:07 PM »

oh dear, i thought it was working quite well.
-nudone (April 10, 2006, 06:01 PM)

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 (April 10, 2006, 06:01 PM)

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.

AndyM · « **Reply #49 on:** April 10, 2006, 06:58 PM »

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 (April 10, 2006, 05:02 PM)

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)