Resizing Windows Bounds Bug

I wrote this script to resize all Applescripts to the same size, and for some reason the saved top window bounds dimension is reduced by 4 pixels, resulting in this odd exception that I have to make to the dimensions of that one window. Apply the script to a few windows to see for yourself.

Anyone have an idea as to why this is happening?

-- Resizes all open Applescripts or an entire Applescript folder based on user choice.
-- The dimensions differ because saved top window bounds are reduced by 4 pixels. 

tell application "Script Editor"
	
	set bounds of front window to {275, 46, 1000, 1050}
	save front document
	
	try
		set filesFolder to button returned of (display dialog "Process open Applescripts or an entire Applescript folder?" buttons {"Files", "Folder", "Cancel"} default button 1)
		
		if filesFolder is "Files" then
			if the (count of documents) = 1 then
				display dialog "There are no currently open Applescript files to process." buttons {"OK"} default button "OK"
			else
				repeat with i from 2 to count of documents
					set bounds of window i to {275, 50, 1000, 1050}
				end repeat
				close (documents 2 thru -1) with saving
				save document 1
			end if
			
		else if filesFolder is "Folder" then
			set theFolder to choose folder with prompt "Please select a folder with Applescript files to process:"
			tell application "Finder" to set theList to (files of theFolder whose kind is "Applescript") as alias list
			repeat with theFile in theList
				open theFile
				set bounds of front window to {275, 50, 1000, 1050}
				close front document with saving
			end repeat
		end if
	end try
	
end tell

Hi pavilion.

I can’t reproduce the problem on my Mojave machine. Setting Script Editor’s front window’s top edge four pixels higher up the screen than the other windows’ top edges, as in your script, simply makes the window four pixels taller than the other windows.

Something to bear in mind though is that Script Editor’s ‘windows’ don’t necessarily equate to script documents. There are also windows for dictionaries, which too are ‘documents’ in SE’s scripting API, as well as the Library and Log History windows, which aren’t associated with documents. Furthermore (again on my machine), if any of SE’s open windows (except for dictionary windows) are closed, they remain visible but document-less to scripts, even though they’re no longer visible on the screen! In fact they continue to exist until Script Editor quits. The Log History window exists as soon as a script’s run in Script Editor and can be detected by that script even if the window’s not “open” in the GUI.

However, I can’t see how any of this is likely to have caused the problem you’re seeing or to have been fixed by your workaround. :confused:

So I’m on Ventura and the only window open is the script editor, and when it runs on itself you can actually see it bump down 4 pixels, and then when it runs with other open scripts, the end result is that its window is shorter at the top by that same amount. Very odd behavior.

If anyone else on Ventura can confirm they’re seeing the same thing that would be helpful.

FWIW, I ran the following script under various scenarios with multiple Script Editor windows open, and I could not reproduce the issue on my Ventura computer.

tell application "Script Editor"
	set bounds of window 1 to {100, 100, 800, 800}
end tell

Could you please run this script below in one window (I’ve commented out the save/close so you can see the results) with your other script window open. When I do, and then cycle your script window on top of mine, it is 4 pixels shorter on top, like this:

tell application "Script Editor"
	
	set bounds of front window to {275, 46, 1000, 1050}
	save front document
	
	try
		set filesFolder to button returned of (display dialog "Process only open scripts or an entire folder?" with icon note with title "Applescript Script Editor" buttons {"Files", "Folder", "Cancel"} default button 1)
		
		if filesFolder is "Files" then
			if the (count of documents) = 1 then
				display dialog "There are no currently open Applescript files to process." buttons {"OK"} default button "OK"
			else
				repeat with i from 2 to count of documents
					set bounds of window i to {275, 50, 1000, 1050}
				end repeat
				--close (documents 2 thru -1) with saving
				--save document 1
			end if
			
		else if filesFolder is "Folder" then
			set theFolder to choose folder with prompt "Please select a folder with Applescript files to process:"
			tell application "Finder" to set theList to (files of theFolder whose kind is "Applescript") as alias list
			repeat with theFile in theList
				open theFile
				set bounds of front window to {275, 50, 1000, 1050}
				--close front document with saving
			end repeat
		end if
	end try
	
end tell

pavilion. I did as you requested and I did see a 4 pixel difference. However, this is because you set the bounds of the front window to {275, 46, 1000, 1050} and the bounds of the other windows to {275, 50, 1000, 1050}. Do I not understand something?

BTW, I changed the y1 value of the front window to 50, and there was no 4 pixel difference–all the open Script Editor windows were the same.

Yeah, me too! I added the reduced bound to compensate for what I thought was this 4 pixel difference but now don’t see it either, so I must have been really tired or something but thanks for confirming it all works!

Okay, so I’m not crazy after all. Please do this. Take the script below, save it to a new file and place it inside a test folder. Then run the script from another window and select the “Folder” option. Let it process both itself and the one inside the folder, and then open the script inside the folder and cycle the windows back and forth and you’ll see they are not the same dimension at the top.

In fact, you can see that when the script runs, the front window already slips down slightly.

-- Resizes all open Applescripts or an entire Applescript folder based on user choice.
-- The dimensions differ because saved top window bounds are reduced by 4 pixels. 

tell application "Script Editor"
	
	set bounds of front window to {275, 50, 1000, 1050}
	save front document
	
	try
		set filesFolder to button returned of (display dialog "Process only open scripts or an entire folder?" with icon note with title "Resize Applescript Windows" buttons {"Files", "Folder", "Cancel"} default button 1)
		
		if filesFolder is "Files" then
			if the (count of documents) = 1 then
				display dialog "There are no currently open Applescript files to process." buttons {"OK"} default button "OK"
			else
				repeat with i from 2 to count of documents
					set bounds of window i to {275, 50, 1000, 1050}
				end repeat
				close (documents 2 thru -1) with saving
				save document 1
			end if
			
		else if filesFolder is "Folder" then
			set theFolder to choose folder with prompt "Please select a folder with Applescript files to process:"
			tell application "Finder" to set theList to (files of theFolder whose kind is "Applescript") as alias list
			repeat with theFile in theList
				open theFile
				set bounds of front window to {275, 50, 1000, 1050}
				close front document with saving
			end repeat
		end if
	end try
	
end tell

I was able to reproduce that bug.

The bug can also be seen by opening a Script Editor window, setting its bounds to {100, 100, 800, 800}, saving the Script, and quitting Script Editor. From that point on, every time I saved, quit, and reopened the script, the vertical window position decreased by 4 pixels to {100, 96, 800, 796} then {100, 92, 800, 792} then {100, 88, 800, 788} and so on.

Yep, that’s what’s happening but I cannot figure out why :slight_smile: you can even see it happening in real time as the script first starts and the script editor window jumps down those four pixels. Any idea why it’s happening?

And yes, is the script editor app doing this, but the workaround is to change the bounds for that window only by four pixels.

Script Editor has a number of bugs and this is one more. The workaround you’re already using seems a good one. I tested with Script Debugger and did not encounter this issue.

Perhaps, but if you’re explicitly setting the bounds by number, it should adhere to that. Also, it is only happening when processing a folder of scripts, not scripts already open, so that looks like a bug rather than intentional.

Fredrik71. I don’t think that’s the issue raised by the OP.

As your are aware, some apps remember the bounds of a window from one session to the next. In my testing, Safari and Script Debugger do and TextEdit does not. Script Editor remembers the bounds but subtracts a certain number of pixels from the y1 and y2 coorindates from one session to the next.

App: a Safari window
Bounds before close: {160, 25, 1410, 880}
Bounds when next loaded: {160, 25, 1410, 880}
Result: position remembered

App: a saved Script Debugger document
Bounds before close: {480, 33, 1440, 820}
Bounds when document next opened: {480, 33, 1440, 820}
Result: position remembered

App: a saved TextEdit document
Bounds before close: {510, 35, 1410, 785}
Bounds when document next opened: {213, 75, 1118, 998}
Result: position not remembered

App: a saved Script Editor document
Bounds before close: {552, 210, 1252, 920}
Bounds when document next opened: {552, 204, 1252, 914}
Result: position remembered but a small number of pixels subtracted from the y1 and y2 coordinates

BTW, the number of pixels subtracted by Script Editor from session to session appear to vary, so the OP’s fixe may not work precisely.

You’re correct that the issue isn’t the resizing of the scripts but the resizing of the script editor window itself. Script Editor is doing something funky with its own window, but in my testing it only happens when processing a folder of closed scripts. As you pointed out with your own testing, the same resizing script on already opened script windows does not cause the script editor window bounds to shrink.

Further, in all my testing under this condition, the only coordinate that gets changed is the top, so this seems unrelated to what you mention above about the script editor shaving off pixels from two sides between sessions. This is about purposely not adhering to an explicit command in the script and basically going rogue!

CORRECTION: I was wrong about this only happening to folder actions. It is only happening when you save the files after processing. So, if you run my script in either manner (files/folders) but allow all the windows to be saved, then the bug presents itself. If you comment out the save/close code so that only resizing takes place, then every window including the script window, resizes as it should directly on top of one another.

pavilion. In my testing, the size of the window is not changed. Instead, the window is moved up by a certain number of pixels (about 4 to 6). I believe that’s what your script does, but I would have to retest to make certain.

Okay, so the whole thing is FUBAR. Even after getting the window bounds to all match, as soon as you save any script for any reason, without making any adjustment to the window size whatsoever, then the top and bottom bounds change by 4 pixels upon re-opening. So I guess it is what it is, but weird nonetheless.

1 Like