[fudster]

Very nice robtrew. I've seen that sort or "where" syntax in Applescripts before. I'll give that a try for my counts script over the next few days.

I also noticed the "tell application id" - I've been wondering about the best way to address the non-default document for my "maybe someday.ofocus" workflow. I'm going to give "tell document id "<doc id>" a try.


robtrew and curt (et al.), I've gathered some decent references on applescript an am going to try to make the time to do some foundational learning about it. I'm always trying to shoehorn these things into my schedule and have hesitated learning Applescript properly, i.e. "I just want to learn enough to get this done." Time I did this right. If you know of good references, or can suggest the quintessential reference, by all means please do...

Cheers, have a great weekend!

[curt.clifton]

I dabbled for a long time, then learned from Matt Neuburg's excellent book. If I was starting again today, I'd probably use AppleScript 1-2-3 by Sal Soghoian.

[curt.clifton]

Nice, Rob, thanks. Do you see an easy way to use the where-queries and still factor out the filtering into a separate handler? I guess one could retrieve the list, filter it, then process it. I'll have to play with the timing on that.

Originally Posted by curt.clifton

I guess one could retrieve the list, filter it, then process it

If one wants to make use of where queries, (to improve performance, for example) retrieval and filtering have to be combined.
(The where clause is part of get syntax, and can't be applied to lists - hence the scope for an efficient implementation).

Originally Posted by curt.clifton

Do you see an easy way to use the where-queries and still factor out the filtering into a separate handler?

You might find a meta-programming route to passing variable arguments to where clauses. (I can't spot a simple one at the moment - run script gets messy if you try to circumvent its overheads - See Matt Neuburg's section on the Run Handler).

Short of this, and given the need to combine filtering with retrieval, the main room for flexibility probably lies in branching, at some level, between multiple retrieval options, each with an alternative hand-coded where clause.

A trade-off, as always, between flexibility and performance, but a useful rule of thumb is to exercise parsimony and discretion wherever possible in the implicit or explicit use of get, by adding a where condition or two - it can make code simpler, as well as faster.

--

[curt.clifton]

Thanks for the interesting food for thought, Rob.

As a programming languages geek, I like to push on the different features of a language to see how far I can take them. I tend to write Applescript as if it's Scheme with fewer parentheses and no call-cc. It's good to be reminded that AS is much faster if the native app is doing the filtering in a single event.

Originally Posted by curt.clifton

It's good to be reminded that AS is much faster if the native app is doing the filtering in a single event.

If no filtering is needed, the project list can, of course, be flattened even more simply:

tell application id "com.omnigroup.OmniFocus"
	set lstAllProjects to my ProjectList(front document)
end tell

on ProjectList(oParent)
	using terms from application "OmniFocus"
		tell oParent
			set lstFolders to folders -- where etc
			set lstProjects to projects -- where etc
			if lstFolders ≠ {} then
				lstProjects & my FolderProjects(lstFolders)
			else
				lstProjects
			end if
		end tell
	end using terms from
end ProjectList

on FolderProjects(lstFolder)
	set lstProject to {}
	repeat with oFolder in lstFolder
		set lstProject to lstProject & ProjectList(oFolder)
	end repeat
end FolderProjects

PS an even shorter (and non-recursive) route to a full project list would be:

set lstProjects to ProjectList("all-projects")

on ProjectList(strFilter)
	tell application id "com.omnigroup.OmniFocus"
		tell front window
			set selected view mode identifier to "project"
			set focus to {}
			tell sidebar
				select library
				set selected smart group identifier to strFilter
			end tell
			set lstProject to {}
			repeat with oTree in trees of content
				set end of lstProject to value of oTree
			end repeat
			lstProject
		end tell
	end tell
end ProjectList

Which can be simply filtered by choosing an alternative smart group identifier string :

"remaining-projects"
"active-projects"
"stalled-projects"
"pending-projects"
"on-hold-projects"
"dropped-projects"
"completed-projects"
--

[curt.clifton]

Rob,

That doesn't filter out folders.

Originally Posted by curt.clifton

That doesn't filter out folders.

It doesn't allow us to query directly on folder properties, but it does give us a flattened and folder-free list of all the projects in the database very easily and flexibly ...

I think it works quite well as a quick response to Fudster's original problem:

I've been having an awful time trying to obtain all the projects in my omnifocus document in Applescript.

Generally, it seems a good idea not to lose sight of OF's built-in querying when drafting scripts - any flat list that can be automatically queried into existence in the content panel can be readily harvested through applescript ...

(and of course, we can save and restore states if we want to avoid GUI side-effects ...)

--

[curt.clifton]

It does not give a folder-free list of all the projects. When I run your script it includes every folder and every project. As you say, it is flattened. You could, of course, filter in the loop to eliminate the folders. I wonder if the difference between what we're seeing has to do with view bar settings that your latest iteration isn't changing.