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!

I dabbled for a long time, then learned from [URL="http://www.amazon.com/AppleScript-Definitive-Matt-Neuburg-PH-D/dp/0596102119/ref=sr_1_fkmr0_2?ie=UTF8&qid=1266014798&sr=1-2-fkmr0"]Matt Neuburg's excellent book[/URL]. If I was starting again today, I'd probably use [URL="http://www.amazon.com/Apple-Training-AppleScript-Sal-Soghoian/dp/0321149319/ref=pd_sim_b_1"]AppleScript 1-2-3 by Sal Soghoian[/URL].

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.

[QUOTE=curt.clifton;73215]I guess one could retrieve the list, filter it, then process it[/QUOTE]

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

[QUOTE=curt.clifton;73215]Do you see an easy way to use the where-queries and still factor out the filtering into a separate handler? [/QUOTE]

You might find a meta-programming route to passing variable arguments to [B]where[/B] clauses. (I can't spot a simple one at the moment - [B]run script[/B] 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 [B]where[/B] 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 [B]get[/B], by adding a [B]where[/B] condition or two - it can make code simpler, as well as faster.

[COLOR="White"]--[/COLOR]

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.

[QUOTE=curt.clifton;73233]It's good to be reminded that AS is much faster if the native app is doing the filtering in a single event.[/QUOTE]

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

[CODE]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[/CODE]

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

[CODE]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[/CODE]

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"
[COLOR="White"]--[/COLOR]

Rob,

That doesn't filter out folders.

[QUOTE=curt.clifton;74126]That doesn't filter out folders.[/QUOTE]

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]I've been having an awful time trying to obtain all the projects in my omnifocus document in Applescript.[/I]

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 ...)

[COLOR="White"]--[/COLOR]

It does [I]not[/I] 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.