WindowExists vs. Profile Switching

[Exergist]

I've been doing some work on automatic profile switching as well as checking for open windows and I've stumbled onto something that may be a bug. My understanding is that the auto profile switching is always checking if the active window title equals certain text (non-case sensitive), and that the {WINDOWEXISTS:} token tells whether or not a window with particular text exists.

Say I have a profile called MyProfile and I've enabled the global option for auto profile switching. Now say that within MyProfile I've enabled profile switching for the window "dogs" and I've enabled the option to execute the command MyCommand when the profile is loaded. MyCommand contains:

Code: [Select]

Set Text [MyWindowTitle] to 'dogs'
Write '[Blue] {WINDOWEXISTS:MyWIndowTitle}' to log
So my understanding is that any time a window called "dogs" is brought into focus MyProfile will load (if it isn't already activated) and MyCommand will immediately execute. Additionally MyCommand should output "1" to indicate that the window "dogs" indeed exists.

However, if I create a folder called "dogs" and then open it MyProfile does activate and MyCommand does execute but {WINDOWEXISTS:} returns "0". I've tried setting MyWindowTitle to "*dogs*" but the result is the same. I've checked through VoiceAttack's "Show window titles" option and VoiceAttack indeed outputs "dogs" to the event log when the "dogs" folder is activated.

Is this some kind of nuance with doing window checking with a folder instead of an application? Or is this behavior a bug?

[Gary]

I'm thinking this relates to not selecting, 'Launch folder windows in a separate process' in your folder options.  I think that will affect what you are trying to do.

https://winaero.com/blog/how-to-start-file-explorer-in-a-separate-process-in-windows-10/

[Exergist]

Thanks for the info Gary, I'll check that out.

As a side thought, would it be possible to add functionality so that the auto switching could also be performed based on the process name tied to the window? I would think that would yield more targeted results than switching by window title.

[Gary]

Not sure how that would help in this case, as the process name would be, 'explorer' and would constantly be switching to a single profile   It would certainly add a decent overhead penalty for the majority at the benefit of the very few that would use it (or understand it), though.

[Exergist]

Understood. I originally found this during my initial development of a Skyrim profile. I haven't tried the "launch folder windows in separate process" option yet, but when my "Skyrim" folder was activated the profile would also activate. So basically this would create a false positive (since the game has the same "Skyrim" window title according to VA) and the profile initialization command that runs after a switch occurs would not work properly (since the window in focus isn't actually the game). For this case specifying "TESV.exe" as the process to search for within the active window to perform the profile switch would yield more accurate results.

I can get around all this by checking {ACTIVEWINDOWPROCESSNAME} or using an inline function that actually looks at the executable path associated with a given window (which I need to do anyway as part of the profile's functionality), but I will still need a way to restart the profile initialization command since I need to protect against the false positive profile switches. This will probably involve inserting a pause loop that continues to check the active window's process name (or executable) and then jumps to the beginning of the initialization command once the correct process name is detected.

It seems a bit odd that even though WindowExists and Profile Switching are both looking at the same information (window title) they return different results. Though I guess based on my testing it must not be that simple.