I want to be able to detect if an aText window is in front, but it runs as a menu bar app (is that also called accessory app or utility app or...?). Window name doesn't return title of the aText window...
Is there a way to do this?
If you mean, is there an efficient, perfect way, I don't think so.
But if you are desperate, and willing to make compromises, I can think of three ways.
-
You can run a macro that "polls" (eg, runs every second) and uses a Find Image action to see if it detects part of the app's visible presence. This will depend on the app, and since you haven't specified the app, there isn't much more to say.
-
You can run a macro that "polls" (eg, runs every second) and uses Apple's fabulous OCR to see if it detects part of the app's textual presence. This will depend on the app, and since you haven't specified the app, there isn't much more to say. This would work quite well if the app appears on the same part of the screen every time you activate it.
-
You can run a macro that "polls" (eg, runs every second) and uses the list of active processes to determine if the app has opened, assuming that the app changes the list of processes when you activate it. This will depend on the app, and since you haven't specified the app, there isn't much more to say.
I think I've used each of these approaches in the past. I'm always proud when I can get the third one working, because that's probably quite efficient.
Do you mean what aText calls the “Main Window”? I'm probably misunderstanding your question, but if this window is in front, then the app is also in front and the window is called exactly the same. Is it then not enough to include one of these criteria?
Oh, sorry, I didn't realize "aText" was an actual app name. I thought the poster meant "a text window" not "an aText window".
Don't worry, that's what I thought at first. I just assume that the app “aText” is meant. 
As a former user of aText I was surprised that it was a menu bar app, since that wasn't how I remembered it. It has been quite a while since I used that application, so I might misremember; however, the video embedded on the Web page for the application does not seem to show it as a menu bar application.
Were you perhaps referring to how the user can select a snippet from the menu bar item for aText?
More fundamentally, what are you trying to achieve by getting the name of the window? As the Wiki recommends:
Avoid the XY Problem of asking about your attempted ​solution​ rather than your actual problem:​
When you are asking a question, ensure you are clear what you are actually trying to accomplish, not just the difficulty you are having in a specific attempt at solving the problem. ​ There may be a much better way to solve the actual problem rather than resolving the difficulty with your specific attempt.
Always include information about a broader picture along with any attempted solution.
Setting up an Application Activate trigger seems to kind of work, but as asked by others, I guess it depends on what kind of windows you are referring to, and if displaying these windows is activating the aText app — Opening windows like Main Window, Make snippet from clipboard, Applications Config, seems to activate the app and this trigger trigger.
As you say aText windows do not seem to be talking well with the %WindowName% token, but if the Application Activate trigger triggers when opening the windows you are interested in, you could use this trigger in conjunction with @Airy's proposed OCR method further up, to scrape whichever textual details you are interested in
These "observations" have been debunked by @kevinb below, sorry for the confusion:
[…]but only when first activating the app through launching (when it here also launches with displaying a window); or when re-launching the app after having clicked away from the last window. It does not trigger if the application is already launched but the last window was closed (not clicked away).
Only through testing here now I realized that this seems to be this trigger's behavior across all apps. As in that this trigger does not trigger if the application that activates is already running, but the last window was closed (not clicked away); even when re-activating this app makes the app spawn a new window.
I must say this behavior surprised me, and I am not sure if what I've observed here is to be expected or not. I'd love for others to chime in on this.
I don't understand how the application has been deactivated in your example. Closing the last window in most Mac applications does not close the application (that is standard Mac behaviour, which contrasts with that under Windows), so it remains active.
Now I do not understand this either …
I was sure I had done so by clicking on another app's window, or through clicking another app's icon in the Dock. But now trying to reproduce my, very late in the night, last night findings I could not reproduce them …
When now actually activating another app, after having closed the last window of the app defined in the trigger, before switching focus back to the first app — the Application Activates trigger triggers as expected. I must have managed to confuse myself, and thank you for pointing it out!
This behavior seems true for aText, making it very possible for OP to use the Application Activates trigger in conjunction with @Airy's proposed methods for OCR further up (only using this trigger instead of the undesirable high frequency polling otherwise needed). Will update my last post with this
1 Like
Ah, I have certainly “been there” too! 
1 Like