Monitoring window (de-)activation without shell messages

[empardopo]

Have you seen the photo? It appears text in pink colour and I don't know why?

The pink background at the opening " and at the closing " I assume indicates an invalid string, but don't panic, the string is valid it's just that your editor does not support continuation sections written in this manner:

Code: Select all

str := " ; notice the "
(
Auto
Hot
key
)"

I have customized my language file(for the editor I'm using) to support this and also distinguish string continuation sections(shown above) from expression continuation as shown next:

Code: Select all

expr := [
(Join, Q C ; Q option for v2
    "Auto"
    "Hot"
    "key"
)]

Based on the cold folding markers, I assume your using S4AHK. You can set it to v2 to avoid the invalid string highlighting. Nonetheless, it's just text editor highlighting and shouldn't affect the script.

set it to V2? What is this?
I'm sorry but I don't understand.
thanks anyway and sorry for the inconvenience.

[mozmax]

You probably didn't understand that this

Code: Select all

loop {
   id := winexist("A")
   if (id = ""){ ; seems to be not necessary...
      sleep 10
      continue
   }
   wingettitle, t,% "ahk_id " .id
   msgbox,% a_index . " " . t
   winwaitnotactive,% "ahk_id " . id
}

waits (at winwaitnotactive). winwaitnotactive does not cause much cpu load, at least if I remember correct. 1 extra ahk-thread + (1 command + 1 function call + 1 call-back call) / focus-change isnt exactly bloated/inelegant.

I'm not sure about that. I checked the source code for AHK v1 and v2 and they both seem to implement WinWaitXXX by using a C++ "for loop". So, it doesn't just wait, it'll setup a loop that runs over and over until a window matches the condition or there's a timeout. In fact, you're using nested loops here (if you count the loop command). In that case, I actually prefer Coco's solution since it doesn't use any nested loops in the implementation I'm thinking for it (at the cost of running a new instance of the AHK interpreter but that happens only once).
With hooks, it would be a simple matter of the system running code which sits in a specific memory address. No constant polling.
Of course, WinWaitXXX is not to be discarded and I will use it through Coco's solution if there's no other way since it does look like it doesn't cause much cpu load. Still, the use of hooks seems to be the best solution regarding intensive usage of window activation/deactivation detection mechanisms but I can't find a way to implement the idea without relying on the default windows shell.

[mozmax]

Have you seen the photo? It appears text in pink colour and I don't know why?

The pink background at the opening " and at the closing " I assume indicates an invalid string, but don't panic, the string is valid it's just that your editor does not support continuation sections written in this manner:

Code: Select all

str := " ; notice the "
(
Auto
Hot
key
)"

I have customized my language file(for the editor I'm using) to support this and also distinguish string continuation sections(shown above) from expression continuation as shown next:

Code: Select all

expr := [
(Join, Q C ; Q option for v2
    "Auto"
    "Hot"
    "key"
)]

Based on the cold folding markers, I assume your using S4AHK. You can set it to v2 to avoid the invalid string highlighting. Nonetheless, it's just text editor highlighting and shouldn't affect the script.

set it to V2? What is this?
I'm sorry but I don't understand.
thanks anyway and sorry for the inconvenience.

empardopo, V2 is the version of AutoHotkey which is currently under development and is designed to make the language more comfortable for all AHK programmers even if it means breaking some compatibility with the stable 1.1.* versions of the language. You can get more information about it at http://ahkscript.org/v2/. Since it's still under development, you don't have to learn it if you don't feel comfortable with it, though.

Warning: AHK v2 is very addictive!

[empardopo]

Thanks!

[Coco]

@empardopo, what I meant was to set Scite4AutoHotkey to use v2 highlighting, I believe it supports v2.

[lexikos]

I checked the source code for AHK v1 and v2 and they both seem to implement WinWaitXXX by using a C++ "for loop".

Checking the active window every 100ms causes negligible CPU usage. Each check takes perhaps 1µs. Probably less, because my benchmarks include script overhead.

On the other hand, if you use an event hook (SetWinEventHook), how often it gets called depends on the type of event. Some events (such as object creation) are called very frequently, or many times in short bursts (such as when a window with many controls is created). Since the hook is running script each time it is called, it could be less efficient than WinWait. (I'm not sure which event you'd use for window activation or whether it is called under any other circumstances.)

Either way, if you have only one script monitoring window activation system-wide, there's probably nothing to be concerned about.

[Post edited when I realized I had been measuring WinExist rather than WinActive, and the two have very different performance.]

[empardopo]

@empardopo, what I meant was to set Scite4AutoHotkey to use v2 highlighting, I believe it supports v2.

Coco, how can I do that?

[mozmax]

Thanks!

You're welcome.

I checked the source code for AHK v1 and v2 and they both seem to implement WinWaitXXX by using a C++ "for loop".

Checking the active window every 100ms causes negligible CPU usage. Each check takes perhaps 1µs. Probably less, because my benchmarks include script overhead.

On the other hand, if you use an event hook (SetWinEventHook), how often it gets called depends on the type of event. Some events (such as object creation) are called very frequently, or many times in short bursts (such as when a window with many controls is created). Since the hook is running script each time it is called, it could be less efficient than WinWait. (I'm not sure which event you'd use for window activation or whether it is called under any other circumstances.)

Either way, if you have only one script monitoring window activation system-wide, there's probably nothing to be concerned about.

[Post edited when I realized I had been measuring WinExist rather than WinActive, and the two have very different performance.]

Thanks for the very detailed information. I'll use the WinWait solution, then. (I had planned to monitor window activation system-wide from the very beginning)
I had this problem for a while now, so I'm glad it's solved!

And, Coco, your usage of custom window message and child script actually gave me the solution to another problem! I was trying to make a part of my script run in the background but with the ability to report back to the parent script. Thanks for that, too!

Anyway, the main problem IS solved! Thanks, everyone!

[Coco]

Related: OnWin.ahk

[empardopo]

Related: OnWin.ahk

Interesting. Thanks!