I’m trying to process all visible (not minimized) windows of all (not hidden) apps.
Collecting a list of windows works fine, except for two problems with Finder windows.
Window list collection:
use scripting additions
use application "System Events"
set visibProcs to a reference to (processes whose visible = true) -- visible apps
set visibWins to (windows of visibProcs whose value of attribute "AXMinimized" is false) -- non-minimized windows
set windowList to {} -- flatten window list
repeat with i from 1 to count visibWins
repeat with j from 1 to count (item i of visibWins)
set end of windowList to (item j of (item i of visibWins)) -- collect windows
end repeat
end repeat
return windowList
EDIT: Obsolete. Problem was caused by running TotalFinder.
((Problem 1: In the return, every visible Finder window appears twice. This could be mitigated with some extra treatment for Finder, but I guess because of the other problem, I need a deeper solution.))
Problem 2: If Finder has >1 window of the same folder open, processing the list with " … item i of windowList … " only processes one of them. I need the index “i” later, so no “every…”.
EDIT: Other apps besides Finder are affected as well if their window names are not unique.
Probably I need another way to reference the windows, but how?
Grateful for ideas or pointers,
lg
EDIT: use scripting additions and use application “System Events” added
I can’t reproduce your first problem. But windows can be misleading when looking at them with System Events because some applications make them invisible rather than closing them and may have invisible windows anyway. I don’t know if that’s the case here.
The second problem is due to the fact that System Events returns “name references” to things which have names. So windows with identical names have identical references and using these always gets the first window with the name. You’d need to arrange your script so that it counted how many windows there were with a certain name and use ‘whose’ references in a repeat loop, eg. ‘window n whose name is thisName’. Of course you’d have to make sure you didn’t do anything to a window to muck up the numbering of others with the same name. And some windows don’t have names, so you also have to be careful how you ask!
Although Apple’s AppleScript representatives gushed over the possibility when it was first introduced, I don’t personally recommend using ‘use’ to include application terminology. Scripts are much easier to read, and you have far more control over where the terminology applies, if you use explicit ‘tell’ statements at the points where the terminology’s needed.
Thanks for taking the time to test and the explanation!
Meanwhile I could track the first problem to the use of TotalFinder (edited in OP), and have filed a bug there. Sorry for wasting anyone’s time who tried to help.
I think it might even be a good idea to make it a general rule not to use name referencing whenever the possibility of a name collision exists.
As for the ‘use’ to include application terminology, would you recommend to avoid it also for, e.g., ‘use scripting additions’, or ‘use framework “AppKit”’?
I think you have to use ‘use’ for frameworks. ‘use scripting additions’ is only necessary if you use ‘use’ for something else and want to use scripting addition commands as well. If ‘use’ isn’t used at all, scripting additions commands are available anyway (although only the StandardAdditions ones since Mojave). An alternative to ‘use scripting additions’ at the top of a script is a ‘using terms from scripting additions’ statement at the point(s) where such commands are needed:
use AppleScript version "2.4" -- This specifies a minimum AppleScript version, but prevents scripting additions from being loaded implicitly.
-- Blah blah blah.
using terms from scripting additions
display dialog "Hello!"
end using terms from
