AppleScript for Finder won't update windows with Mavericks

Scripting Forums AppleScript | Mac OS X
#1

Hallo,

“Stopped working with Mavericks” seem to be one of the most asked questions here. So here another one.

I have several variations of this rather simple little AppleScript for Finder:


tell application "Finder"
    activate

    set |Window| to get Finder window 1

    set the current view of |Window| to icon view

    set |View Options| to icon view options of |Window|

    set the icon size of |View Options| to 256
    set the label position of |View Options| to bottom
    set the shows item info of |View Options| to true
    set the shows icon preview of |View Options| to true
    set the arrangement of |View Options| to arranged by name
end tell

In the past this worked quite nicely and changed the top window into the desired appearance. But not any more. The properties are actually changed to desired values but the change only reflects in the GUI after a Finder restart. Which kind if defeats the object of a appearance-change script.

Any ideas?

#2

Hello.

I discovered that at least when changing icon size, I have to refresh the finder window, by changing its target temporarily.

Maybe this thread can be helpful.

#3

Hi, McUser. I tried your method and it worked once and then, inexplicably, never again. :frowning: I find that, if you open and close the window, the folder updates consistently; this is a hack for an obvious bug, though.

tell application "Finder" to tell Finder window 1
	set trg to its target
	set the current view to icon view
	set its icon view options's properties to {icon size:75, label position:bottom, shows item info:true, shows icon preview:true, arrangement:arranged by name}
	close
	open trg
end tell
#4

Hello.

I find that strange, I have done it some times now… :slight_smile: But truth to be told, something has happened a couple of times, and that is that the window opened in list view. brb, as I look for a hack by Crhistopher Stone, that I just remembered.

#5

Thanks for the link. The new, now working version is:


tell application "Finder"
	activate
	tell Finder window 1
		set current view to icon view
		
		set its icon view options's properties to {icon size:64, label position:bottom, shows item info:true, shows icon preview:true, arrangement:arranged by name}

		-- we refresh the window to reflect the icon size change!
		set Original_Target to its target as alias
		set Parent_Target to container of its target as alias
		set target to Parent_Target
		set target to Original_Target
	end tell
end tell

Martin

#6

Hello.

I can’t find the hack, that involved using SystemUIServer, to somehow “tickle” the front Finder Window so that it updates, if somebody knows what I am talking about, and where to find it, don’t be shy. :slight_smile:

So Marc, if opening and closing is the only way to make it work for you, then I’m sorry. (Have you tried to insert a slight delay?)

Maybe it will work repeatedly if you restart Finder?

#7

Isn’t what you describe a task for :

update‚v : Update the display of the specified object(s) to match their on-disk representation
update specifier : the item to update
[necessity boolean] : only update if necessary (i.e. a finder window is open). default is false
[registering applications boolean] : register applications. default is true

Yvan KOENIG (VALLAURIS, France) dimanche 17 novembre 2013 16:48:31

#8

Looked at update but could not get it to work as I could not figure out which “item” is needed.

#9

Hello.

I couldn’t make update to work, when I tried to update target of the window, which is what I understood to be the correct object from the AppleScript Users Mailing list post.

I didn’t use the necessity then, but it didn’t make a difference when I used that parameter now. (with necessity).

I have also tried to activate SystemUIServer, then perform action “AXRaise” on first Finder window, I guess that when I have done this and it didn’t work, then changing the index briefly of the Finder window wouldn’t make any difference as well.

But changing the target, now that will force finder to update! :slight_smile:

#10

Hi,

Ok, so now can anyone tell me how to set the windows back to default! :slight_smile:

Thanks,
kel

#11

What do you mean? Maybe you should have a look at the thread two threads earlier or so, OP = Polish Prince.

#12

Hi McUsr,

There is a default Finder setting for windows and there a user set default setting. I couldn’t find anything that would set a window or windows back to the default settings.

#13

Hello.

I filed a bug : 15490571 at bugreporter. If this is an issue that is important to you, I think you should file a bug as well, to give it more weight.

#14

Update the folder which you are displaying.
Yvan KOENIG (VALLAURIS, France) lundi 18 novembre 2013 12:30:25

#15

If you mean from keyboard, from the Finder “View” menu pick “Show Window Options” (or command-J) and then change the button [Use as Defaults] to [Restore to Defaults] by holding the “option” key and click on restore.
If you mean from AS, I don’t know if the user’s default view can be called directly. I have handlers for setting each property for the list, column and icon default views.

#16

Do your handlers still work for setting properties in the various views? -I have to test out my own as well. It would be nice to put all the bugs on the table as soon as possible.

I don’t decorate Finder Windows a lot, but at least the ones that sorts a listview on modification date, name respectively, has ceased to work. I think I’ll see if there are any workarounds before I file any bug reports.

It isn’t too bad, if one only can make it work somehow, as those bugs saves battery. :slight_smile:

Edit

My scripts had stopped working, but I just applied the code from above to change the target of the window for a brief, and then everything started working correctly again.

#17

Hi Flex,

Forgot about the Option key in the View Options. I think it was the same in 10.2.8 (Jaguar).

Thanks,
kel

#18

Same with my handlers and the same workaround suggested above. Hopefully, Apple will deal with the bugs quickly. There are quite a few in the new recoded Finder.

#19

Hi,

I have used the update command in the past.

But please note I did use this a long time ago and my understanding of it is based on a memory from a brain like a sieve :wink:

The example I give may throw some light on what it is for or at least what I used it for. ( remember the above note)

We have network volumes that files from FTP are dropped into.

One problem with this is the finder did not always update because of network lag or some such thing.

You could have two macs and the volumes mounted on both but they would be out of sync in what they showed. This also include any label index colours.

So I had a script that would run every so often to update the finder.

The key thing is that it is the files of the window that I wanted to update.

Meaning I had a window that represented the file system but it was not up to date in displaying what the file system actually had on disk. Therefor did not show me all the items .i.e the files.

So I told the finder to update that representation.

If I remember correctly ( I do not use it any more and it was a while back) the code would simply be

tell application "Finder"
 update items of windows 
end tells

or

tell application "Finder"
	update items of window "images"  
end tell

You could use the files specifier of even file

tell application "Finder"
 	set fld to "Macintosh HD:Users:markhunte:Sites:index.html" as alias
	
	update fld  
	
end tell

So as far as I am aware this will not work on updating the view options…

#20

Hey Folks,

Yvan Koenig very accurately put it this way:

“If the sum of the defined [visible] column widths is smaller than the width of the window, the first column is given the greater possible width so that the entire window is used.”

The rest is most of what I posted on ASUL about a ten days ago. I haven’t gotten back to it yet, but I have a number of scripts to fix and will when I get frustrated enough.

set altTarget to path to favorites folder
tell application "Finder"
	if front window exists then
		set _target to target of front window as alias
		if _target = altTarget then set altTarget to path to home folder
		tell front window
			set bounds to {0, 44, 1040, 1196} # Must be less than the aggregate column widths.
			if current view ≠ list view then
				set current view to list view
			end if
			tell its list view options
				set width of column id creation date column to 141
				set width of column id modification date column to 141
				set width of column id size column to 97
				set width of column id name column to 450
			end tell
			set target to altTarget
			set target to _target
		end tell
	end if
end tell

Mavericks broke my old window-resize/column-resize scripts, so I’ve spent some time fiddling with it and have an imperfect workaround.

I think we’re dealing with both bugginess in the Finder, and a change in the way it displays windows in list-view.

In Mavericks when you zoom a window beyond its columns the name column automatically widens, and this breaks the current name-width-setting in that window.

Depending upon the window width and the columns visible (other than the name column) it may or may not be possible to set the width of the name column AND changing the bounds of the window MAY break the name-width-setting you just set via Applescript.

So for experimental purposes you can reduce the columns in your front window to name, mod-date, and size. Then run my script. Then resize the window by hand. Try widening it. Try reducing the width.

Then turn on cre-date, kind, comments, and tags and run the script again.

This time it works - as long as you don’t widen the window width beyond the sum of its columns.

You’ll also notice that the changed width of the name-column is not registered unless you change the target and then jump back.