Wait so can I use this along with the script that you helped me edit that uses UIElements to connect to bluetooth devices so that it would seem like I had not even opened up system preferences to connect to the bluetooth device?
I am sorry for this whole thread, but it works as should at my place.
With auto-swoosh enabled and all. It is practical, but its not comfortable, and perfect in any sense I realize that now.
Hi McUsr,
That is a puzzle. How do you make just one window of an app frontmost? does it work? I’ll read it later. Interesting.
Hello.
There are certain situations where that won’t work, and that is, when there are more than one window in another space, from that app which window you want to bring to the foreground, as it is I have no way of bringing just that window forward.( if it is followed immediately by an window of the same app, in the z-order (front to back ordering of the windows).
I hope you try it, and find it useful.
I am still working on it, to make it more friendly, as even I are at a loss at times.
Later today, I’ll post a new version, this version will gather all windows, from the app that are active in the current space, regardless, if it has only one window open there, or not. I’ll also use “Stone’s ticks” on the windows that are from the current space, to differentiate between “native” and “foreign” windows.
OK.
Even more bugfixes, when a user escapes out of a choose from list, and leaves the screen in a more tranquil state, with regards to windows visible, and frontmost, before and after a cancel.
All windows for an app will be visible in the window list dialog, if it has any, but this behaviour can be changed by a property.
There is no way to just activate a window from an app in another space, and bring that to front, without bringing the windows of that app in your current space to front. So the price for jumping to a window in another space, is that you rearrange the window layout in your current space. The second caveat is that all windows of the same app will be brought to front, once activated, because I have to activate the app, to make the jump to the window.
This could have been fixed by ui scripting the window menu, and jump from there, right now I am fed up with it… 
Hello.
It still disrupts your screen a whole lot less, when you have many windows open in an app, compared to the usual way of getting a window: activating an app, and then looking for the window.
And, my test shows that it disrupt the screens less than command tab (choose app ) 1.
So. In my eyes, it is an improvement, although small. (Not worth it.)
(You really need to have auto-swoosh enabled to see any benefits by this script, this is described in post #7 where you also find the script.
Hello.
I had to implement a time out for cases where the app you want to get a window list from is busy, and then bail out with a dialog about the situation.
This doesn’t happen often but say if you left an app in a modal dialog, then it may.
Hi McUsr,
I downloaded the Pike script from post #7. Chose Smile and had open a new untitled script window and the worksheet. When I choose the worksheet from the dialog, the untitled window comes up. When I choose the untitled window the worksheet becomes frontmost. I’ll try to look through the script to see what is happening.
Nice idea though. I always want to bring some window from some app frontmost. I always used to bring the app to the front first, then try to click on the right window.
Later,
kel
Thank you very much kel! One - nil to Hawaii! 
It was nice of you to tell me. It appears that since Smile, operates with several kinds of windows, both AppleScript Terminals, Dialogs and AppleScripts, that may “Trick” to bring a window frontmost doesn’t work. I have implemented a work-around for Smile, so that the correct window gets to be activated.
I have tested the script alot, and that is the first time just that has happened.
Please tell me, if you find other flaws.
In the passing. I wrote the script for some of the same reasons, most of my apps aren’t assigned to any space, so that they get started in the space that I am in. Those apps where I have a window open that covers all contexts, (my working contexts) are set to show up in every space.
If I did this with the apps, that I may use in a separate space on a project, then I would have all its windows cluttering up everything. So this program enables me to jump into a space, and have that window I want active when I get there. Then it is easy to jump back with the window.
Pike diversifies your options with regards to window configuration of your spaces. That was what I was trying to say. Or. Pike gives you an option in between of everything and nothing. But it is intended to be used with auto-swoosh, as described together with the script in post #7.
Enjoy your evening!
Foggy morning here.
Hello.
I have changed login name, and can’t access the script in post #2 Elevate: So I’ll post the update here, which aren’t much more than embedding the script into a script object, and then running it, because that speeds things up.
This little script is very practical, when you are having many windows open in the same space, because it lifts forward, the current window of an app, but lets the rest be untouched.
I have placed this in an AppleScript action in an Automator service like this:
End I have gone into the keyboard preferences pane, and assigned it to cmd-F3.
(My keyboard is configured so that I have to press the ‘fn’ button in order to adjust the volume by F11/f12).
Together with the ‘cycle through windows buttons’ (shift-cntrl-F4 and cntrl-4) this gives me an easy window-activation from the keyboard.
Here is the updated script:
-- Elevate http://macscripter.net/viewtopic.php?pid=154619#p154619
-- © McUsr and put into public domain (Parts stolen from MacOSXAutomation.com )
-- http://macosxautomation.com/mavericks/notifications/01A.html
-- revised to use current application instead of system ui server
property parent : AppleScript
on run
try
script o
property a : missing value
property b : missing value
end script
local a, b, c, d, i
set e to (path to frontmost application as text)
tell application id "com.apple.systemevents"
set {o's a, o's b} to {bundle identifier, name} of (every process whose visible is true)
set pcount to count o's b
repeat with i from 1 to pcount
if (count every window of (application process (item i of o's b))) = 0 then
set {item i of o's a, item i of o's b} to {missing value, missing value}
else if (frontmost of (application process (item i of o's b))) = true then
set ebid to item i of o's a
set {item i of o's a, item i of o's b} to {missing value, missing value}
end if
end repeat
end tell
set {o's a, o's b} to {o's a's text, o's b's text}
set pcount to count o's b
set deli to "." & space & space
repeat with i from 1 to pcount
set item i of o's b to character id (i + 96) & deli & item i of o's b
end repeat
tell application id "com.apple.systemuiserver"
activate
try
with timeout of 30 seconds
set c to (choose from list o's b default items item 1 of o's b with title "Elevate a window")
end timeout
on error thisErr number thisNr
if thisNr = -1712 then
tell application id "com.apple.systemevents"
tell process "SystemUIServer"
tell button 2 of its window 1 to click
end tell
end tell
set c to false
end if
end try
end tell
if c = false then
do shell script "/usr/bin/open -b " & ebid & " &>/dev/null &"
error number -128
else
do shell script "/usr/bin/open -b " & item ((id of character 1 of (item 1 of c)) - 96) of o's a & " &>/dev/null &"
end if
on error errorMessage number theErrNo
if theErrNo is -25211 then
my addAppletToAccessibilityList()
else if theErrNo ≠-128 then
tell application (path to frontmost application as text)
display dialog "Elevate got an Error: " & errorMessage & " : " & theErrNo
end tell
end if
end try
end run
-- stolen from MacOSXAutomation.com
on addAppletToAccessibilityList()
set thisApplication to (path to frontmost application)
tell application "Finder" to reveal thisApplication
tell application "System Preferences"
launch
reveal anchor "Privacy_Assistive" of pane id "com.apple.preference.security"
activate
display alert "ADD APPLICATION TO ACCESSIBILTY" message "In order to let this application control the computer by running Elevate, it must must be added to the list of applications approved to use the accessibility controls of the OS." & return & return & "To add this Application to the Accessibility list:" & return & return & "1) Click the lock icon (if it is locked) at the bottom left of the System Prefences window, and enter your adminstrative password in the forthcoming dialog." & return & return & "2) If the Application is already in the list, select the checkbox next to its name. Otherwise, drag the icon of the applet (now revealed in the Finder) into the list area displayed on the right side of the System Preference window." & return & return & "3) Click the lock icon to re-lock the preference pane."
end tell
end addAppletToAccessibilityList
I have a snippet like this in my script folder, so I can run it from the scripts menu as well.
property parent : AppleScript
set hfsScriptName to "Macintosh HD:Users:you:path to:Elevate.scpt"
run script (hfsScriptName as alias)
Hello.
I have updated the script in the post above, so that it gives a clear message when it can’t be activated due to the fact that it isn’t in the list of applications approved to use the accessibility controls of the OS.
Thanks to this post at MacOSXAutomation.com: AppleScript System Notifications Support (advanced), I found a snippet that lets you activate the SecurityPreferences pane of an app, when the frontmost app haven’t that approval.
This lets the script/service tell us, when the script doesn’t work due to the fact that it isn’t enabled for Assistive devices, in a user friendly way, thanks to the great dialog written at MacOSXAutomation.com, together with the revelation of the app, so that you can drag it into the list with approved applications of the security preferences pane, if it isn’t already there!
Enjoy!
Hello.
I had a bug in the script in post #30 because I didn’t expect that other things than that the frontmost application weren’t approved on the access for assistive devices list, could raise an error.
This bug is now resolved.
” And I am sorry for any inconvenience!
Hello.
I have weeded out one more bug in the script in post #30, the bug was that I didn’t take height for System Events not returning a process list on some occassions, now the front most process is saved up front.
If you don’t see the gear icon after having used a short cut key to invoke the frontmost window, then it is time to open op Activity monitor if it isn’t running, and check for items reading “Automator runner doesn’t answer” or similar.
The reason for this may be that the app you had in front when running the service, wasn’t on the approval list for using UI access in the first place. I am digging more into this, to see if I can trap the situation.
Again. I’m sorry for any inconvenience.
Hello.
I have updated both the automator service, and the script in post #30.
I did experiment some with the Automater Service, because sometimes, it seemed like it just died, especially with a high system load.
By having the script run from within a current application block it seems like that issue is removed.
Because this has a different effect on the script I have now rewritten the part of the script that deals with the user choosing “Cancel”, so that it still just reactivates the previous window that was open.
Hello.
The IAutomator Action in post #30, is changed considerably.
Since I can’t control the sensibility of the keyboard from an automator action, I often trigged the service several times at once from the keyboard.
Now, we upsate the timestamp on the time on every successful run, and if the current time - the modification time is less than, or equal to 2 seconds, we ignore to run the Elevate AppleScript.
Hello.
I have changed the AppleScript in post #30.
What happens when an application is not approved of using assistive devices is now more gracious, with regards to the number of dialogs. The choose from list, has been embedded in a with timeout clause, and the choose from list is closed upon timeout. The elements of the choose from list, is indexed with lower cap letters, to make the selection faster, when apps start with the same name.
Hello.
This is a considerably faster version of the Automator service in post #30.
The reason for that I post the version here, is that, I am unsecure as to when the date comand on OS X got the %s option, since the Automator action, relies on this. Other than that, the single line of do shell script, replaces 20 odd lines of AppleScript.
Enjoy!
Hello.
I revised the script in post #30 while I was at it. The call to the indexOfItem handler wasn’t really needed anymore, since I index the item with letters in ascending order. So, I just reversed the calculation, for setting the index letter.The calulation of the list index of the corresponding bundle id, at least runs faster in the ScriptEditor, than using indexOfItem.
Should you wish some other means of indexing the items, then a similiar approach can be taken for calculating the index number.
Hello.
I optimized the script in post #30 further: I removed the embellishing script and the run statement of it, since that seemed to only have negative impact when run from Automator (thru the Applescript action posted in post #37.
I really can’t measure how fast this is, but it seems like the choose from list dialog opens faster than the find dialogs in some apps, and I don’t perceive them as slow. So I am happier with it now.