AHK Window Info 1.7
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.
CleanNews.in : Bite sized latest news headlines from India with zero bloat
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.; - when started with "HideGui" turned on: GUI starts hidden, after 500 ms data is collected and GUI shown
; - changed licence to Attribution-NonCommercial-ShareAlike 2.5 licence from Creative Commons
toralf
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.
CleanNews.in : Bite sized latest news headlines from India with zero bloat
That will convince Chris for certain to add it. ;)
toralf
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.
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).by default not rectangle is drawn around controls
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.Would a one-click mode be of any use? Instead of auto-update every xxx milliseconds, the data would only be updated at each mouseclick (outside the GUI).
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.reduced impact in hidden mode on CPU load to nearly 0
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:
[*:9n9mfwsm]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.
[*:9n9mfwsm]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.
[*:9n9mfwsm]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 )<<<<".
[*:9n9mfwsm]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.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.
I can't reproduce it.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.
I like it to have it in 4 different fields.Advanced tab can be de-cluttered and shrunk even more by eliminating the two "slow text" boxes at the bottom.
I can't do it, since I do not have Win9x. Could someone please test it?final QA review such as testing it on Windows 9x.
Changes:
First post is updated.;changes since 1.4
; - "H" replaced with Hwnd; "P" and "S" with "Pos" and "Size" on advanced tab for Control
; - GroupBox names have bold font
; - Mouse color picker is only updated when mouse tab is visible. Otherwise set to gray
; - set default for color picker to 15x15, since it only influences CPU load when the mouse tab is visible
; - controls list items are only updated when advanced tab is visible. Otherwise set to ">>>not updated<<<""
; - windows statusbar text is only updated when advanced tab is visible. Otherwise set to ">>>not updated<<<""
; - fast/slow visible/hidden window text are only updated when advanced tab is visible. Otherwise set to ">>>not updated<<<""
;todo
; - Window Info should be tested on Windows 9x
toralf
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.
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.I can't reproduce it.Sometimes pressing Window Info's minimize button fails to work.
If no one beats me to it, I've made a note to test it on Win9x prior to distribution.I can't do it, since I do not have Win9x. Could someone please test it?
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.; - GroupBox names have bold font
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.; - Mouse color picker is only updated when mouse tab is visible. Otherwise set to gray
; - set default for color picker to 15x15, since it only influences CPU load when the mouse tab is visible
The reduction in CPU load is quite noticeable. Thanks for going through the trouble.; - controls list items are only updated when advanced tab is visible. Otherwise set to ">>>not updated<<<""
; - windows statusbar text is only updated when advanced tab is visible. Otherwise set to ">>>not updated<<<""
; - fast/slow visible/hidden window text are only updated when advanced tab is visible. Otherwise set to ">>>not updated<<<""
Here are a few more suggestions:[*:kwud9zag]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.
[*:kwud9zag]Minor typos in source code comments: "or less or" should be "or else" in 2 places.
[*:kwud9zag]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.
Normally the script does this:
If (PosX > -4 and PosY > -4) IniWrite, x%PosX% y%PosY% , %IniFile%, Settings, Gui1Pos...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:
WinGet, Gui1MinMax, MinMax, %WinNameGui1% if (Gui1MinMax != -1) ; not minimized (if it was, PosX and PosY would be something like -32000) IniWrite, x%PosX% y%PosY% , %IniFile%, Settings, Gui1PosThis 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?
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.
toralf
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.
http://www.autohotke...ands/SysGet.htm
I'm talking about:
78, 79
SM_CXVIRTUALSCREEN, SM_CYVIRTUALSCREEN: Width and height of the virtual screen, in pixels. The virtual screen is the bounding rectangle of all display monitors. The SM_XVIRTUALSCREEN, SM_YVIRTUALSCREEN metrics are the coordinates of the top-left corner of the virtual screen. Windows NT, Windows 95: The retrieved value is always 0.
You should also check the several "Monitor" subcommands.76, 77
SM_XVIRTUALSCREEN, SM_YVIRTUALSCREEN: Coordinates for the left side and the top of the virtual screen. The virtual screen is the bounding rectangle of all display monitors. By contrast, the SM_CXVIRTUALSCREEN, SM_CYVIRTUALSCREEN metrics (further above) are the width and height of the virtual screen. Windows NT, Windows 95: The retrieved value is always 0.
_______________________
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.Don't know if it's of any help, but SysGet offers some possibilities around multidisplay environments.
I have one of my monitors hooked up to my xbox atm, but I'll be sure to get around to this eventually.
toralf
I use the latest AHK version (1.1.15+)
Please ask questions in forum on ahkscript.org. Why?
For online reference please use these Docs.