13 replies to this topic

[AEN007]

8March2010

Greetings.
Once again I am encountering Exclude Text problems ...
(I suppose some helpful guest might reply that I should stop whining?)

I have encountered more than once that AHK does
not exclude text that the documentation says AHK should ...
AHK has incredible documentation but sometimes
the documentation is not clear (to me) ...
My understanding is that
MatchMode Slow/Fast, 1/2/3 and DetectHiddenText (DHT)
affect how/what AHK detects as window text.

The WindowSpy shows Visible/Hidden & MatchMode Slow text.
AHK should detect all/any text with MatchMode Slow/2 & DHT On.

My most recent problem is with the Configuration window for The Clock
<!-- m -->http://www.softpedia... ... lock.shtml<!-- m -->
(freeware & install-free / only one release and no longer supported ...)

WinGetText, OV, WinTitle/Class retrieves all text that the WSpy shows
but WinMove (for example) does not "catch" any/all exclude text
that I understand WinMove should -
no matter if MM is slow/fast 1/2/3 or DHT is On or Off ...

AHK only seems to detect the FIRST text element listed under visible text.
WSpy lists a different text element first for each tab of TheClock configuration ...
This is not the first time that AHK has only detected the first text element listed -
regardless of MM 1, 2 or 3; Slow or Fast, DHT On or Off

WSpy says TheClock config window has only one hidden text element,
but AHK WinMove would not exclude the window with DHT On ...

I would be interested to hear/discuss anyone else's experience
with AHK & The Clock Configuration window ... for example

Any helpful replies/insights appreciated.
Thank you.
Regards,
AEN
Æ

[sinkfaze]

The title of the window is 'Configuration', there's no other text in the window title to exclude. I can move the window fine with this:

WinMove, Configuration, , 0, 0

So if that's not your issue you need to please be sure to state exactly your problem is and provide code so we can see what you're doing versus what you're expecting.

[AEN007]

10March2010

Greetings.

I totally forgot to mention MatchMode RegEx.
I thought maybe someone would jump all over the posting about that ...
I only use RegEx in exceptional situations. RegEx is fun.
I tried RegEx with The Clock exclude text to no avail.

The title of the window is 'Configuration', there's no other text in the window title to exclude

Excuse me but my understanding is that WinTitle and WinText are
totally separate and distinct. (I can't believe I have to state that ...)
"The Clock" Config window has TONS of text.
For example WSpy lists "UTC" as visible text for each tab even though
"UTC" only appears as text on the last tab ...

On one of my XP laptops I want a (Persistent) script to move all windows
(that might open at any time) with Config in the TiTLE (except "The Clock") to -5, 55.
I should be able to distinguish "The Clock" config window
from all other windows with Config in the TiTLE by using

SetTitleMatchMode 2
SetTitleMatchMode Fast
WinMove, Config, ,-5, 55, , , , UTC

but AHK "exclude text" does NOT catch "UTC" as text
in "The Clock" Config window even though WSpy says it should ...
AHK "exclude text" only catchs the first text element listed by WSpy.
"The Clock" Config window has five tabs without a common first text element ...

It seems to me that AHK "exclude text" DOES NOT work like I understand that it should ...

Any helpful replies/insights appreciated.
Thank you.
Regards,
AEN
Æ

[sinkfaze]

Are you sure AHK is supposed to catch it? The window text changes in the configuation window depending on which tab you are viewing. As far as I can tell 'UTC' exists only when you are under the Atomic Time tab, so if that tab isn't active when you execute that script it isn't going to work.

[AEN007]

11March2010

Greetings.

1) WSpy seems have a problem/BUG with its visible text -
at least when spying on certain types of tabbed windows.

I just discovered the following »
WSpy lists as visible text all text from the active tab
PLUS ALL TEXT from any/all previously viewed tabs!
WSpy does this with The Clock tabbed window,
the XP StartMenu & Taskbar tabbed window,
the XP Display tabbed window ...

WinGetText does not have that problem.

2) My point regarding the AHK exclude text BUG still remains!
Pick any (correct/actual) visible "TEXT" item
OTHER THAN THE FIRST TEXT ITEM WSpy lists for the active tab.

Try
WinMove, Config, "TEXT",-5, 55
then try
WinMove, Config, ,-5, 55, , , , "TEXT"

WinMove with include text will work but WinMove with the same exclude text will NOT.

Then try the same with "TEXT" as the first text item that WSpy lists.
AHK WinMove will then work correctly with the TEXT as either include or exclude text ...

It seems to me that AHK "exclude text" DOES NOT work like I understand that it should ...
I hope/wish the right person @ AHK woulld address this(these) issue(s).

Any helpful replies/insights appreciated.
Thank you.
Regards,
AEN
Æ

[Lexikos]

After briefly looking through the relevant sections in the source code (WinExist, EnumParentFind, WindowSearch::IsMatch and EnumChildFind), I believe it currently "works" like this:
[*:lhi8fmtn]Commands call ::WinExist() to resolve the WinTitle etc. to a window handle.
[*:lhi8fmtn]WinExist calls EnumParentFind once for each top-level window, via EnumWindows.
[*:lhi8fmtn]EnumParentFind calls IsMatch to determine if the current candidate is a match.
[*:lhi8fmtn]IsMatch checks the title; if the title matches, it calls EnumChildFind once for each child window (control) of the current candidate top-level window, via EnumChildWindows.
Where aWnd is the handle of the current child window:
[*:lhi8fmtn]EnumChildFind compares aWnd's text to the ExcludeText; if the excluded text is found, it stops enumeration (IsMatch returns false). Otherwise, if WinText is empty or matches aWnd's text, it sets mFoundChild=aWnd and stops enumeration (IsMatch returns true).In other words, the first child window which contains the WinText or ExcludeText determines whether the parent window is considered a match. Instead, I think EnumChildFind should do this:
[*:lhi8fmtn]If aWnd's text matches ExcludeText, set mFoundChild=NULL and stop enumeration. IsMatch will return false.
[*:lhi8fmtn]If mFoundChild has not yet been set and aWnd's text matches WinText, set mFoundChild=aWnd and continue enumeration.In other words, after finding the first matching child window, enumeration continues to ensure that no other child windows contain ExcludeText. (Edit: See patch.)


Since this bug has (presumably) been around so long, I assume very few users actually use the ExcludeText parameter. A while back I tried using a RegEx - when it didn't work, I assumed RegEx wasn't supported in ExcludeText. I now know that TitleMatchMode RegEx is supported for WinText/ExcludeText, but match modes 1 and 3 aren't supported: "for backward compatibility" they act like mode 2.

Also note that as explained above, WinText/ExcludeText must match text from any single control, not the text of all controls as shown in Window Spy.

[AEN007]

20March2010

Greetings.
Thanks for the reply.

I still stand by what I have stated above/previously.

1) WSpy seems have a problem/BUG with its visible text -
at least when spying on certain types of tabbed windows.

2) I have encountered more than once that AHK does
not exclude text that the documentation says AHK should ...

I was already aware that ExcludeTitle/Text were orphan AHK children.
<!-- m -->http://www.autohotke... ... highlight=<!-- m -->

It seems to me that AHK should take some action regarding my two points above.
I would prefer that AHK would fix WSpy & ExcludeText.
IncludeText catches any/all actually visible text per MatchMode.
ExcludeText does NOT.

Windows whose text include this value will not be considered.

All of the related AHK documentation regarding ExcludeText
is incorrect, inaccurate - misleading. The AHK WSpy documentation
does not account for the "TabbedWindowBug".

It is not clear to me why you state the following»

Also note that as explained above, WinText/ExcludeText must match text from any single control, not the text of all controls as shown in Window Spy.

Nothing I have previously posted infers anything of the sort.

Any helpful replies/insights appreciated.
Thank you.
Regards,
AEN
Æ

[Lexikos]

You will get no-where by repeating yourself, especially when I've already reaffirmed your (ExcludeText) point and shown how it could be fixed. It is up to Chris to take action.

It is not clear to me why you state the following»

I mentioned it for the benefit of all users reading this topic; because it is related and contrary to what the documentation implies, and because I noticed it while investigating the issue you reported.

I was already aware that ExcludeTitle/Text were orphan AHK children.
<!-- m -->http://www.autohotke... ... highlight=<!-- m -->

Firstly, your statement makes little sense; I assume you mean you were aware that text elements/controls/child windows are scanned independently, not the window's text as a whole like the documentation implies. Secondly, the thread you've linked contains nothing to back up your claim as far as I can tell.

Regarding Window Spy,

ahk2exe, AutoScriptWriter, and Window Spy are 99% the work of the AutoIt authors Jon and Larry.
Source: Three thumbs up!

As far as I know, the source code for Window Spy is not available. This is why I did not comment on or test your claim. I recommend you use AHK Window Info instead. Its behaviour should be identical to other AutoHotkey scripts.

The AHK WSpy documentation

Does it even exist?

[AEN007]

29March2010

Greetings.

This weekend I found that AHK does detect text on not visible tabs
IF those tabs have been previously active!
I guess that is why WSpy works the way it does.
I was redoing my script for launching/running the XP cleanmgr.
Text on the second tab (include NOT exclude - of course)
would not be detected until after the second tab had been active at least once.

I wish AHK exclude title would do ahk_class/ID/PID & etc like include title does.

Thank you.
Regards,
AEN
Æ

[jaco0646]

ExcludeTitle doesn't support ahk_pid and similar things. All it does is what the help file says: "Windows whose titles include this value will not be considered." The reason for this is that the added code size doesn't seem justified given how rarely ExcludeTitle is used.

Early on in the project, Chris considered eliminating the feature entirely. It was never intended to have full functionality and will not be updated.

[AEN007]

3April2010

Greetings.
Thanks for the reply.

OK ... whatever ...
It seems (to me) that identifying windows is at the heart/core of what AHK is/does.
The better ExcludeTitle/Text work - the better AHK works.
This resistance to ExcludeTitle/Text functionality seems counterproductive to me.

The AHK ExcudeText documentation is incorrect/inaccurate/misleading
in that ExcludeText does not catch any/all text items like IncludeText does.

[jaco0646]

Until such time as the documentation is updated, anyone with questions regarding ExcludeText should be pointed to this thread, to see the more thorough explanation by Lexikos. The behavior is now unofficially documented.

[This thread is locked. ~jaco0646]