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

jgpaiva · « **Reply #75 on:** May 02, 2006, 02:52 PM »

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.

nudone · « **Reply #76 on:** May 02, 2006, 03:16 PM »

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.

jgpaiva · « **Reply #77 on:** May 02, 2006, 05:32 PM »

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

As this version has more settings in the ini file, please delete it before executing this version.

nudone · « **Reply #78 on:** May 03, 2006, 01:09 AM »

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.

jgpaiva · « **Reply #79 on:** May 03, 2006, 05:03 AM »

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.

nudone · « **Reply #80 on:** May 03, 2006, 08:40 AM »

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.

AndyM · « **Reply #81 on:** May 03, 2006, 08:47 AM »

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.

jgpaiva · « **Reply #82 on:** May 03, 2006, 09:03 AM »

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

nudone · « **Reply #83 on:** May 03, 2006, 09:40 AM »

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.

AndyM · « **Reply #84 on:** May 03, 2006, 04:38 PM »

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 (May 03, 2006, 09:40 AM)

Same here

jgpaiva · « **Reply #85 on:** May 03, 2006, 05:54 PM »

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

nudone · « **Reply #86 on:** May 04, 2006, 01:13 AM »

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.

jgpaiva · « **Reply #87 on:** May 04, 2006, 07:36 AM »

both screen top and screen right set to '0' after i click on the 'okay' button.
-nudone (May 04, 2006, 01:13 AM)

Ok.. At least i know what's NOT in the origin of this problem

I'll continue digging, then..

jgpaiva · « **Reply #88 on:** May 04, 2006, 07:56 AM »

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

AndyM · « **Reply #89 on:** May 04, 2006, 10:00 AM »

i think this might be it.

-jgpaiva (May 04, 2006, 07:56 AM)

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

jgpaiva · « **Reply #90 on:** May 04, 2006, 10:05 AM »

(..)it worked just fine!
I too think this might be it.
-AndyM (May 04, 2006, 10:00 AM)

You can't imagine how happy that makes me!

How about you, nudone?

AndyM · « **Reply #91 on:** May 04, 2006, 11:04 AM »

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

[Select]

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

jgpaiva · « **Reply #92 on:** May 04, 2006, 11:21 AM »

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

AndyM · « **Reply #93 on:** May 04, 2006, 12:12 PM »

... 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 (May 04, 2006, 11:21 AM)

This would be very cool!

nudone · « **Reply #94 on:** May 04, 2006, 01:13 PM »

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.

nudone · « **Reply #95 on:** May 04, 2006, 01:31 PM »

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"

[Select]

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

AndyM · « **Reply #96 on:** May 04, 2006, 01:32 PM »

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 (May 04, 2006, 01:13 PM)

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

nudone · « **Reply #97 on:** May 04, 2006, 01:37 PM »

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.

AndyM · « **Reply #98 on:** May 04, 2006, 01:41 PM »

[Select]
If WinHeight > 151 ;nudone
return ;nudone

;If WinHeight > %PredefWinHeight%
; return
;If WinWidth > %PredefWinWidth%
; return
-nudone (May 04, 2006, 01:31 PM)

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

)

AndyM · « **Reply #99 on:** May 04, 2006, 01:42 PM »

Oops, nudone, you already figured this out and posted your reply.

I need to type faster!