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

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

I sure hope this feature can be toggled off if it's implemented.
-AndyM (April 10, 2006, 06:58 PM)

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

Sorry, i don't quite understand what you mean.

Btw, howcum I've never had the shrinking problem? (not that I'm complaining)
-AndyM (April 10, 2006, 06:58 PM)

You know what? you might have the solution for the our problem!

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

AndyM · « **Reply #51 on:** April 10, 2006, 09:51 PM »

You know what? you might have the solution for the our problem!
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

AndyM · « **Reply #52 on:** April 10, 2006, 09:54 PM »

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.

jgpaiva · « **Reply #53 on:** April 11, 2006, 02:17 AM »

v 1.0.42.03
-AndyM (April 10, 2006, 09:51 PM)

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

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

For not having the hotkeys, you could have set the "hotkey" variable to false

But the short time I used the .ini file, I didn't have shrinking windows, other than the Help file thing.
-AndyM (April 10, 2006, 09:51 PM)

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

Ok, i understand your point. But don't worry, you'll still be able to use it like that.

jgpaiva · « **Reply #54 on:** April 11, 2006, 02:17 AM »

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

Yes, that's the behaviour i get now, too, since i added that margin.

AndyM · « **Reply #55 on:** April 11, 2006, 07:38 AM »

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

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
-jgpaiva (April 11, 2006, 02:17 AM)
-AndyM (April 10, 2006, 09:51 PM)

Understood. I just mention that I don't need the hotkey function, so not having an .ini file doesn't cause me a problem.

AndyM · « **Reply #56 on:** April 11, 2006, 08:35 AM »

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.

[Select]

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

nudone · « **Reply #57 on:** April 11, 2006, 01:28 PM »

any updates?

jgpaiva · « **Reply #58 on:** April 11, 2006, 04:15 PM »

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

(I'm sory I still don't have a webpage to put all this links, but i hope to have one soon.)

AndyM · « **Reply #59 on:** April 11, 2006, 07:09 PM »

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!

nudone · « **Reply #60 on:** April 12, 2006, 02:33 AM »

excellent news, unfortunately i won't be able to try it until later tonight.

nudone · « **Reply #61 on:** April 12, 2006, 10:27 AM »

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.

jgpaiva · « **Reply #62 on:** April 12, 2006, 11:16 AM »

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

Good to know that!

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

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

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

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

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!

nudone · « **Reply #63 on:** April 14, 2006, 05:01 PM »

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.

jgpaiva · « **Reply #64 on:** April 14, 2006, 05:28 PM »

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!

nudone · « **Reply #65 on:** April 15, 2006, 01:56 AM »

excellent. enjoy the break.

jgpaiva · « **Reply #66 on:** April 19, 2006, 01:12 PM »

I'm just checking in to say i didn't forget that update, just been a bit busy (with school work), but i'll get to it as soon as possible. Sorry.

nudone · « **Reply #67 on:** April 19, 2006, 02:11 PM »

no rush, i greatly appreciate all your time spent on the project.

AndyM · « **Reply #68 on:** April 21, 2006, 08:13 AM »

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!

jgpaiva · « **Reply #69 on:** May 01, 2006, 06:54 AM »

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

nudone · « **Reply #70 on:** May 01, 2006, 07:24 AM »

excellent. i'll try it later tonight.

nudone · « **Reply #71 on:** May 01, 2006, 03:22 PM »

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

jgpaiva · « **Reply #72 on:** May 01, 2006, 06:42 PM »

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?

nudone · « **Reply #73 on:** May 02, 2006, 01:23 AM »

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.

nudone · « **Reply #74 on:** May 02, 2006, 01:46 PM »

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.