Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

AHK Window Info 1.7


  • Please log in to reply
82 replies to this topic
Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004
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.

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
Thanks Rajat, for clarifying.

I implemented it a bit different. But I guess I got it as you want.

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

I updated the souce code in first post and added screenshots of the options.
Ciao
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.

Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004
thanks a lot toralf! ... i think my personal version of win-spy that i'd been using for long now, will finally be ditched!

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
:) The first prominent user!
That will convince Chris for certain to add it. ;)
Ciao
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.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

by default not rectangle is drawn around controls

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

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

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.

reduced impact in hidden mode on CPU load to nearly 0

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:
[*: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.

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005

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

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 can't reproduce it.

Advanced tab can be de-cluttered and shrunk even more by eliminating the two "slow text" boxes at the bottom.

I like it to have it in 4 different fields.

final QA review such as testing it on Windows 9x.

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

Changes:

;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

First post is updated.
Ciao
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.

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Sometimes pressing Window Info's minimize button fails to work.

I can't reproduce it.

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 do it, since I do not have Win9x. Could someone please test it?

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

; - GroupBox names have bold font

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.

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

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.

; - 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<<<""

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

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.

newrui
  • Guests
  • Last active:
  • Joined: --
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.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Yesterday, 07:41 AM
  • Joined: 24 May 2006
Code looks great.

Well done.
Posted Image

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
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:
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, Gui1Pos
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?

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
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
 
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.

AGU
  • Guests
  • Last active:
  • Joined: --
Don't know if it's of any help, but SysGet offers some possibilities around multidisplay environments.

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.

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.

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

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

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

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

jholmes_gt
  • Members
  • 1 posts
  • Last active: May 06 2007 07:11 PM
  • Joined: 22 Apr 2007
I am thourouhly impressed with this proram. One of the best I've ever seen written in AutoHotkey.
get out what you put in

toralf
  • Moderators
  • 4035 posts
  • Last active: Aug 20 2014 04:23 PM
  • Joined: 31 Jan 2005
Thanks a lot. Much appreciated.
Ciao
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.