AutoHotkey Community

for my usage, i did a little change to the code.
in the auto-exec section i added:
SetTimer, PauseAction, 500

and at the end of PauseAction section i added:
SetTimer, PauseAction, Off

this is kind of what i failed to clearly explain in my last posts' wishes. maybe an option for something similar could be added?... what i actually want is that when the script is loaded, it updates once and then auto-pauses.

_________________

Thanks Rajat, for clarifying.

I implemented it a bit different. But I guess I got it as you want.I updated the souce code in first post and added screenshots of the options.

_________________
Ciao
toralf

thanks a lot toralf! ... i think my personal version of win-spy that i'd been using for long now, will finally be ditched!

_________________

:) The first prominent user!
That will convince Chris for certain to add it. ;)

_________________
Ciao
toralf

Although it may be disappointing to some not to have the red rectangle by default, I suspect your decision is best for compatibility and performance (perhaps you had other reasons).

Although it might be useful to some, I suspect such left-clicks might too often have undesirable side-effects in the control beneath the cursor. I know it's tempting to have a lot of modes and options in AHK Window Info to try to please everyone. I think you've done a good job of compromising by relegating rarely-used options to the separate/advanced section.

The CPU load is generally very good now. The only thing I don't like is that when a tab other than Advanced is selected, the load gets heavy when the mouse cursor is over a ListView (and perhaps other times), which implies that the script is updating all the tabs. On old/slow PCs, it would be a great benefit to avoid the possibility of such a high load when the Advanced tab isn't visible.

More detail from an old e-mail: Rather than updating the info in the hidden tabs, perhaps you could save the window-id, control-hwnd, and mouse coords so that if the user happens to stop the update then show another tab, the tab could refresh itself by fetching text and colors from the saved items. The color grid would be a problem since the window might now be hidden behind some other window -- but the reduced CPU load might be worth the inconvenience of having to manually refresh it, especially since colors are somewhat rarely used compared to other fields.

A possible side-benefit to the above change is that you could go back to a default color grid of 3x3, which might improve the default appeal and functionality of that tab.

Here are some other comments:

• In the advanced tab (and possibly others), I suggest making the GroupBox names a bigger font (or bold or a different color) to bring more attention to them, which seems justified given how important some of their names are.
• Sometimes pressing Window Info's minimize button fails to work. Instead, the window blinks but stays where it is. If you can't reproduce it, I can try to figure out the steps that make it happen.
• Although the advanced tab is shorter now, I think it can be de-cluttered and shrunk even more by eliminating the two "slow text" boxes at the bottom. They're usually empty anyways; but in cases when they're not, their contents can be shown/appended in the boxes above them by using a separator such as "`n`n>>>>( TitleMatchMode=slow Text )<<<<".
• The merging suggested above might allow greater clarity in the wording of other control labels. For example, "H" seems too obscure (Hwnd seems better). "P" and "S" aren't as bad, but "Pos" and "Size" would be clearer if there's any way to fit them.

Finally, AHK Window Info is looking great and I appreciate how receptive you've been to my suggestions in the past. I don't think there's much more that needs to be done before distributing this with AutoHotkey -- perhaps just a final QA review such as testing it on Windows 9x.

Thanks.

I don't like the idea of updating the data at a later time. It might have chnaged in-between. I rather like the user to tell that it is not updated and let him get the data again.

I can't reproduce it.

I like it to have it in 4 different fields.

I can't do it, since I do not have Win9x. Could someone please test it?

Changes:First post is updated.

_________________
Ciao
toralf

It seems to happen only when the Advanced tab is selected and only when Window Info isn't the active window. About 1 out of 3 times, I press the minimize button directly (without first activating Window Info) and the window blinks (disapppears momentarily or redraws) then stays where it is. Although I don't see any explanation for it in your GuiSize label, this issue doesn't seem to occur in any other GUI scripts.

If no one beats me to it, I've made a note to test it on Win9x prior to distribution.

This caused a wrapping problem where the last letter is cut off on XP Classic Theme (and perhaps others), apparently due to an OS bug. Please add -wrap (minus wrap) to each bold GroupBox because testing shows this fixes it.

Increasing the grid seems good. Although the big grid maxes my CPU when the mouse is moving quickly, users probably won't mind because the color picker is the main reason to be on that tab.

The reduction in CPU load is quite noticeable. Thanks for going through the trouble.

Here are a few more suggestions:

• Defaulting to RGB vs. BGR isn't optimal if the majority use BGR for PixelSearch. I'm not sure how we could find out, but perhaps AHK v2 will offer a conversion routine so that the BGR mode can be eliminated entirely (along with other v1-to-v2 translations). In the meantime, we could have a poll or just make BGR the default.
• Minor typos in source code comments: "or less or" should be "or else" in 2 places.
• One thing I hope you'll forgive me for not mentioning earlier: I don't like the fact that by default, moving the mouse over Window Info while it isn't active causes it to display its own title/info instead of the active window's. It defeats the ability to easily copy the WinTitle/Class like you can in Window Spy, which is my most common usage. The ability of Window Info to display info about its own window and controls (at least when on the Simple tab) doesn't seem important enough to have it enabled by default; so perhaps it could be made an option that's disabled by default.

Thanks for everything.

Just want to say that this is a great script, many more functionalities than Window Spy. I am looking forward to the next enhancement version coming out. Hope it'll be included in the AHK package.

Code looks great.

Well done.

_________________

I've encountered a slight problem with AHK Window Info in multi-monitor setups: the script assumes anything above/to the left of -4,-4 is not a valid position. I like to put AHK Window Info on my secondary screen, which is to the left of my primary. The exact position is something like x-312 y146.

Normally the script does this:...so the position of the window is not saved if it is on my secondary monitor. This effectively causes it to reset to the previous "valid" position (still stored in the .ini file.)

What's worse is that the previous position isn't always valid - sometimes I set my displays to "horizontal span" mode, where the top-left of the secondary screen is at x0 y0 instead of x-1024 y0 (in "dual view" mode.) If I put the Window Info on my primary monitor (at roughly x1280 y0), close Window Info, then switch back to "dual view" mode and re-open Window Info, it ends up completely off-screen...

My temporary solution is this:
This will save the window position as long as the window isn't minimized.

I might have a go at writing a helper function for saving and restoring window positions, with multiple-monitor bounds checking (so the window is guaranteed to never be put off-screen.) It seems like something that would be useful even for single-monitor setups... Has it been done before?

Hi Lexikos,

Thanks for the feedback. Since I do not have multiple monitors, this never was a problem for me. It would be great, if you could find a robust way to determine the current position on a multi-monitor setup. AFAIK, this hasn't been done yet. Only a few people have this kind of setup.

_________________
Ciao
toralf

Don't know if it's of any help, but SysGet offers some possibilities around multidisplay environments.

http://www.autohotkey.com/docs/commands/SysGet.htm

I'm talking about:

You should also check the several "Monitor" subcommands.
_______________________
Cheers AGU

Yes, I think the Monitor sub-commands will be sufficient for validating a screen position. It's just a matter of working on the logic. For example, the position could be saved as "screen number, relative position", allowing it to fall back to the same position on the primary monitor, if whatever screen it was on was disconnected. It would also need to check the size of the screen it is on, so that it doesn't get put off-screen. The idea would be to provide an easy-to-use framework, so that any other scripts with a "persistent GUI state" can benefit. The "position validation" part would have its uses in single-display setups, if, for example, the user changes screen resolutions occasionally.

I have one of my monitors hooked up to my xbox atm, but I'll be sure to get around to this eventually.

I am thourouhly impressed with this proram. One of the best I've ever seen written in AutoHotkey.

_________________
get out what you put in

Thanks a lot. Much appreciated.

_________________
Ciao
toralf