Sequioa - asking for columns in Finder window's list view results in 256 list items

[ccp]

tell application "Finder" to set _c to every column of list view options of window 1

On Sequioa this results in 256 list items where items 1 thru 249 are “name column” and the rest are “real columns” like “modification date” etc.
Am I the only one?
Never had this on High Sierra

Thanks for any hint!

EDIT:

Okay, I found this thread:

Finder list-view option of visible columns

The AppleScript Finder dictionary contains the following list-view column property: “visible (boolean) : is this column visible” However, the following script doesn’t work: tell application "Finder" tell list view options of front Finder window set visible of column id modification date column to false end tell end tell I thought perhaps this property was meant to be read-only but even that doesn’t appear to work. I googled this and others have reported a similar issue and suggested GUI…

The problem seems to have existed since at least 2019; probably in every macOS version since High Sierra.

[VikingOSX]

Maybe this is what you want:

use scripting additions

tell application "Finder"
	activate
	set newWin to (make new Finder window with properties {current view:list view, sort column:name})
	set target of newWin to (path to desktop)
end tell

tell application "Finder" to set c to name of every column of list view options of Finder window 1

Result:

{name column, modification date column, creation date column, size column, kind column, label column, version column, comment column}

[ccp]

Thank you very much, VikingOSX – I think this will help.

[Nigel_Garvey]

@VikingOSX

tell application "Finder"
	activate
	set newWin to (make new Finder window with properties {current view:list view, sort column:name})
	set target of newWin to (path to desktop)
end tell

I was going to point out in response to VikingOSX’s suggestion that the Finder’s make command has an optional to parameter which can be used to specify the target of the Finder window being created:

tell application "Finder"
	activate
	set newWin to (make new Finder window to desktop with properties {current view:list view, sort column:name})
end tell

However, testing it in the above form before posting has led to the interesting discovery that, in the case of the desktop, the window that opens also contains the mounted volume(s) and groups the desktop items by stack, if any are set. The alternative forms below produce the same window contents as VikingOSX’s script:

tell application "Finder"
	activate
	set newWin to (make new Finder window to (path to desktop) with properties {current view:list view, sort column:name})
end tell

tell application "Finder"
	activate
	set newWin to (make new Finder window to folder "Desktop" of home with properties {current view:list view, sort column:name})
end tell

[VikingOSX]

Thanks Nigel for the clarification. I thought I tested it this way but evidently not…

[ccp]

Could someone please try the following script?

• I have 3 Finder windows open, all in list view

• I activate window 1 and run the script
  Result of each variable = 8 items (= correct)

• I activate window 2 and run the script
  Result of each variable = 16 items

• I activate window 3 and run the script
  Result of each variable = 256 items

How can that be? I don’t understand this at all …

use scripting additions

tell application "Finder"
	activate
	set lview_options to list view options of window 1
	-- resulting variables lists:
	set lview_column_names to name of columns of lview_options
	set lview_column_visibles to visible of columns of lview_options
	set lview_column_widths to width of columns of lview_options
	set lview_column_sort_directions to sort direction of columns of lview_options
end tell

[Nigel_Garvey]

Hi @ccp

The anomaly seems to be associated with a window’s target rather than the window itself. On my Ventura machine, your script returns 9 name columns and seven others for a window that’s open on my main user’s Downloads folder. If I switch the window to another folder, only one name column and the seven others are returned.

Interestingly in the case of my Downloads folder, while getting the columns or their properties returns 16 items, counting the columns in the application (count columns of lview_options) returns 8. Accessing a column using an index specifier of 8 or lower returns a name column, but trying to access a column using an index specifier greater than 8 causes an error. Also, whose filters based on column properties only only appear to consider the first 8 (ie. name) columns. (Clearly the Finder knows there should only be eight columns.) The other columns and their properties can all be accessed using name specifiers, such as index of column size column of lview_options.

I’ve not been able to identify anything about my Downloads folder that might cause these results. I think they’re get-roundable for scripting purposes, so apart from the infuriation of not knowing what’s causing them, it’s probably not worth worrying about them.

[ccp]

Thank you for checking it out, Nigel.
The script is part of a larger one. To make it executable, I shortened the variable list to the last 8 variables using an if-then condition.
Thanks again & have a nice day!