I am looking at getting the frame of the largest possible window for any screen with the dock in any position, visible or invisible.
I thought I had it when I added a shortcut to menu zoom (command d) that (like clicking the green button) zooms the window to full available screen and back.
This zoom respects the menu bar and the dock wherever it is located. i.e the window does not go under the dock even if it left or right.
This seemed to be a good alternative to coding the dock position and height and the menu bar.
The only thing left now is to allow for the Finder having a 22 pixels taller menubar than other apps.
but… (with my luck) as you can see below theFrame is equal to theFrame2. i.e when you read the zoomed window you still get the original un-zoomed size.
Does anybody know why?
script AppDelegate
property parent : class "NSObject"
property aWindow : missing value
on applicationWillFinishLaunching_(aNotification)
-- Insert code here to initialize your application before any files are opened
set theFrame to (aWindow's frame()) --
log "theFrame:"
log theFrame
--aWindow's setFrame_display_animate_({{0, 0}, {1920, 1200}}, true, true) -- this always slides the window under the dock, except when it is at the bottom
tell application "System Events" to keystroke "d" using command down
-- delay 1 or do shell script "sleep 1" did not help
set theFrame2 to (aWindow's frame())
log "theFrame2:"
log theFrame2
end applicationWillFinishLaunching_
on applicationShouldTerminate_(sender)
-- Insert code here to do any housekeeping before your application quits
return current application's NSTerminateNow
end applicationShouldTerminate_
end script
I am not going to write a novel about this. I think Finder is returning, and acting upon content rect, and not frame rect.
I usually get reasonable answers when I peek into window values by system events and application process’s first window.
If the values then aren’t returned in a uniform way, with respect to windows, which I believe they are, then they are at least returned in an updated state. Or was, on Snow Leopard. (My window handling routines works still.)
If you are after the size of a window, before or after you resize it, then the code below should be pretty much bullet proof, when dealing with System Events, as the appname does not have to be the same as the process name.
on frontproc_wn()
set appid to id of (application (path to frontmost application as text))
tell application "System Events"
tell application process ((name of every application process whose bundle identifier is appid) as text)
if (count windows) > 0 then
set {pos, sz} to {position, size} of its window 1
else
set {pos, sz} to {{0, 0}, {0, 0}}
end if
end tell
end tell
return pos & sz
end frontproc_wnCount
set theFrame to current application's NSScreen's mainScreen()'s visibleFrame()
is exactly what I was looking for. Gets me the bounds without having to zoom in and out again.
I tried to understand how get screens() would work.
set theScreens to class of current application's NSScreen's screens() -- __NSArrayI
set theScreens to current application's NSScreen's screens() as record --> {}
-- these below return a different value each time I call them, I cannot understand why
set theScreens to current application's NSScreen's screens() --> ("<NSScreen: 0x600000462040>") --> ("<NSScreen: 0x608000079f40>")
set theScreens to item 1 of current application's NSScreen's screens() -- <NSScreen: 0x600000079a00> --> <NSScreen: 0x60000026acc0>
I only have one screen connected. Would I get a different return if I had 2 or I am Ijust going the wrong way about it?
Thanks to you too McUsrII.
Unfortunately your code needs assistive access. As per Mavericks it is not possible to auto enable it in System Preferences so I’d rather stay away from it.
(My window handling routines works still.)