Using where / whose clauses is generally quite a lot faster (and simpler to write) in Applescript than iterating with repeat loops and applying tests.

For efficient recursive walks through nested outlines, one really wants to be able to distinguish, within a where statement, between those nodes which have children and those which are childless leaves.

This is not as easy in OmniFocus as it is in OmniOutliner, in which the Applescript library provides the useful has subtopics property.

Has anyone found an elegant or efficient idiom for doing something similar in OmniFocus ?

A rather clumsy, and rather inefficient-looking idiom which does at least work is:

where (container of (tasks of tasks) is tasks)

which filters for childless (taskless) projects or tasks, so a rather unreadable equivalent of has subtopics is

where not (container of (tasks of tasks) is tasks)

To see a list of projects which have no tasks, for example, you could write:

tell application "OmniFocus"
	set oDoc to default document
	set lstChildless to my ChildlessProjects(oDoc)
	set focus of front document window of oDoc to lstChildless
end tell

on ChildlessProjects(oParent)
	using terms from application "OmniFocus"
		tell oParent
			set lstProjects to projects where (container of (tasks of tasks) is tasks) and ((status is active) or (singleton action holder is true))
			set lstFolders to folders where hidden is false
		end tell
		repeat with oFolder in lstFolders
			set lstProjects to lstProjects & my ChildlessProjects(oFolder)
		end repeat
		return lstProjects
	end using terms from
end ChildlessProjects

But I suspect that something more efficient and legible should be possible ...

Any thoughts ?

--

[curt.clifton]

I haven't come up with anything better. I played with things like count of tasks of task is 0, but without success. I wasn't very persistant in my efforts though, since I have recursions that do the job reasonably well.

It would be really helpful if there were a command to get all the tasks in a tree as a flat list filtered by where clauses. Most of the gyrations in scripting OF seem to have to do with manually walking the trees.

[Tim Wood]

I've added some tiny scripting updates in OmniFocus 1.8 (r134083) that may help make these sorts of tasks easier.

Document and folder now have a "flattened projects" relationship which returns an in-order traversal of the projects within the specified container.
Document now has a "flattened tasks" relationship which returns an in-order traversal of the entire task tree in the document (including the inbox).

Tasks now have three additional properties:

• number of tasks
• number of available tasks
• number of completed tasks

which reflect internal counters that we are maintaining anyway.

For this job, you might be able to do something like:

tell application "OmniFocus"
	tell default document
		every flattened project whose number of available tasks is 0 and status is active
	end tell
end tell

I hope this helps!

Originally Posted by Tim Wood

Document and folder now have a "flattened projects" relationship which returns an in-order traversal of the projects within the specified container.
Document now has a "flattened tasks" relationship which returns an in-order traversal of the entire task tree in the document (including the inbox).

Tasks now have three additional properties:

• number of tasks
• number of available tasks
• number of completed tasks

Wow ! Words which sound like the falling of welcome rain :-)

I really appreciate the time and thought which you have put into doing that work ...

Thank you, Tim !

PS as a very short term fix, for anyone holding on the Sneaky Peek builds, it turns out that non-leaf nodes were findable in a marginally less clumsy fashion than I had previously stumbled on with:

tasks where (tasks of tasks) is not tasks

and terminal leaves were harvestable with:

tasks where (tasks of tasks) is tasks

Happily, due to the excellent work which Tim has modestly announced, these slightly baroque formulations are now, at best, of rather obscure antiquarian interest :-)

Originally Posted by RobTrew

these ... formulations are now, at best, of rather obscure antiquarian interest :-)

Although, (unless Tim happens to feel that there is scope for bringing contexts up to date with projects ?) this kind of idiom would, at present, still be needed if we wanted to use whose / where clauses to flatten the OF Context tree.

To get a flattened list of active contexts for example, you could currently write:

tell application "OmniFocus"
	set oDoc to default document
	set lstContexts to my ActiveContexts(oDoc)
end tell

on ActiveContexts(oParent)
	using terms from application "OmniFocus"
		tell oParent
			set lstContexts to contexts where (hidden is false) and (allows next action is true)
			set lstParental to contexts where (contexts of contexts) is not contexts
			repeat with oContext in lstParental
				set lstContexts to lstContexts & my ActiveContexts(oContext)
			end repeat
		end tell
		lstContexts
	end using terms from
end ActiveContexts

This could be very drastically shortened, however, (and the sequence of the harvest made more rational), with the excellent approach that Tim has brought to the folder, project and task tree ...

--

[curt.clifton]

Originally Posted by Tim Wood

I hope this helps!

Woot! Very, very nice. Thanks.

[Tim Wood]

"flattened context" is available on document and context as of r134086. I've also added "flattened task" on task.

Thanks for the feedback!

The flattened lists are already working well, and very welcome.

Not sure if others are seeing this, but there seems to be an initial glitch with the very promising family of three new number of ... tasks properties.

I am getting AppleEvent handler failed messages from the following, in Late Night Software's Script Debugger (and the script produces no output if launched from the OF script menu).

(Sneaky Peeks 1.8 Revision: 134152)

tell application "OmniFocus"
	set oProject to first item of flattened projects of default document
	tell oProject
		set lngAvailable to number of available tasks
		set lngCompleted to number of completed tasks
		set lngTasks to number of tasks
		
		display dialog ((lngAvailable as string) & tab & lngCompleted as string) & tab & lngTasks as string
	end tell
end tell

--

Originally Posted by RobTrew

Not sure if others are seeing this, but there seems to be an initial glitch with the very promising family of three new number of ... tasks properties.
--

( This turned out to only affect OS X 10.5 and earlier, and has been fixed for sneaky peek 1.8 r134216 )