The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus Extras
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Acting on all projects using Applescript Thread Tools Search this Thread Display Modes
Quote:
Originally Posted by RobTrew View Post

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 ...)
My experience is that changing and restoring the GUI states is more work and substantially slower than using recursion.
__________________
Cheers,

Curt
 
Quote:
Originally Posted by curt.clifton View Post
My experience is that changing and restoring the GUI states is more work and substantially slower than using recursion.
Perhaps it depends on how much state you are aiming to conserve.

Just saving and restoring the filter states is simple to do and runs quite fast:

Code:
set lstView to GetView()
set lstProjects to ProjectList("all-projects")
RestoreView(lstView)
lstProjects

on GetView()
	tell application "OmniFocus"
		tell front window
			tell sidebar
				set strSideID to selected smart group identifier
			end tell
			tell content
				set strGroupID to selected grouping identifier
				set strSortID to selected sorting identifier
				set strDurnID to selected task duration filter identifier
				set strFlagID to selected task flagged filter identifier
				set strStateID to selected task state filter identifier
			end tell
		end tell
		{strSideID, strGroupID, strSortID, strDurnID, strFlagID, strStateID}
	end tell
end GetView

on RestoreView(lstView)
	set {strSideID, strGroupID, strSortID, strDurnID, strFlagID, strStateID} to lstView
	tell application "OmniFocus"
		tell front window
			tell sidebar
				set selected smart group identifier to strSideID
			end tell
			tell content
				set selected grouping identifier to strGroupID
				set selected sorting identifier to strSortID
				set selected task duration filter identifier to strDurnID
				set selected task flagged filter identifier to strFlagID
				set selected task state filter identifier to strStateID
			end tell
		end tell
	end tell
end RestoreView

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
			-- set focus to lstProject
			lstProject
		end tell
	end tell
end ProjectList
 
Although creating and then closing a temporary window is even simpler ...

Code:
set lstProjects to ProjectList("all-projects")

on ProjectList(strFilter)
	tell application id "com.omnigroup.OmniFocus"
		tell front document
			tell (make new document 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
				close
			end tell
		end tell
	end tell
	lstProject
end ProjectList
 
How big is your database? My original recursive script with individual item filtering takes less than a second against my database. The one that opens a new window takes over 7 seconds.

I'm not trying to have a pissing contest here. You're definitely right about not overlooking the built-in filtering capabilities, but neither should we ignore a recursive solution, especially when it's more efficient.
__________________
Cheers,

Curt
 
Quote:
Originally Posted by curt.clifton View Post
You're definitely right about not overlooking the built-in filtering capabilities, but neither should we ignore a recursive solution, especially when it's more efficient.
Yes, my personal preference is for recursion too - something very elegant and pleasing about it. Here I would probably go for the recursion + where query option.

For a programmer in a hurry, however, the brief non-recursive code might give a good trade-off between programming time and run time. It's certainly quite easy to understand and maintain.

Generally, I think this kind of talmudic debate is quite productive.
It explores the search space and the cost/benefits pretty thoroughly, and one finds things that one might otherwise have overlooked, and which might prove useful later ...

I look forward to the next one :-)

--

Last edited by RobTrew; 2010-05-31 at 11:47 PM..
 
Quote:
Originally Posted by RobTrew View Post
I look forward to the next one :-)
Likewise, but first I have to convert a bunch of my scripts to better use where clauses! :-)
__________________
Cheers,

Curt
 
In case anyone looks to this thread for a solution, a couple of updates come to mind.

My current summary of the faster where-query approach might have the form:

Code:
tell application "OmniFocus"
	set oDoc to default document
	set lstProjects to my ProjectList(oDoc)
	-- set focus of front document window of oDoc to lstProjects
end tell

on ProjectList(oParent)
	using terms from application "OmniFocus"
		tell oParent
			-- ADJUST THE WHERE QUERIES TO MATCH THE PURPOSE
			set lstProjects to projects where (status is active) or (status is on hold)
			set lstFolders to folders where hidden is false
		end tell
		repeat with oFolder in lstFolders
			set lstProjects to lstProjects & my ProjectList(oFolder)
		end repeat
		return lstProjects
	end using terms from
end ProjectList
While the non-recursive (but slower) approach based on named filters can be speeded up a little by getting a value list from a reference, to avoid iteration.

Code:
-- AVAILABLE FILTERS:
-- 	"all-projects"
-- 	"remaining-projects"
-- 	"active-projects"
-- 	"stalled-projects"
-- 	"pending-projects"
-- 	"on-hold-projects" 
-- 	"dropped-projects"
-- 	"completed-projects"

property pFilter : "all-projects"
property pProject : "project"
property pAny : "any"
property pNone : "none"
property pAll : "all"

set lstProjects to ProjectList(pFilter)

on ProjectList(strFilter)
	tell application id "com.omnigroup.OmniFocus"
		tell default document
			tell (make new document window)
				set selected view mode identifier to pProject
				set focus to {}
				tell content
					set selected grouping identifier to pNone
					set selected sorting identifier to pNone
					set selected task duration filter identifier to pAny
					set selected task flagged filter identifier to pAll
					set selected task state filter identifier to pAll
				end tell
				tell sidebar
					select library
					set selected smart group identifier to strFilter
				end tell
				-- value list from a reference (avoids iteration)
				set lstProject to value of trees of content
				close
			end tell
		end tell
	end tell
	lstProject
end ProjectList

--

Last edited by RobTrew; 2010-06-01 at 01:24 AM..
 
The Applescript library enhancements recently made by Tim Woods in the Sneaky Peek 1.8 builds now hugely simplify this kind of task.

To see a list of projects which lack available actions, for example, you could now write:

Code:
tell application "OmniFocus"
	tell default document
		set focus of front document window to 
			(flattened projects where number of available tasks is 0) as list
	end tell
end tell
(Note that these applescript enhancements will be a feature of ver 1.8, and this script will not work in ver 1.7)

--

Last edited by RobTrew; 2010-06-23 at 05:47 AM..
 
Very cool stuff.

I've actually been holding off on the 1.8 sneaky peek - the biggest reason is actually that I'm concerned about subtle changes and problems in applescript support. I depend on my scripts for my hour-to-hour workflow and if just one or two of them became broken, I'd be hosed until they were fixed, one way or the other. I've done skeakypeeks before (all but the last two) and there weren't many AS problems - but I do recall a couple things breaking that took a day or two to fix.

I haven't been following closely, except a glance every so often to see if it's getting close to GA. I see here that there are probably some new opportunities to simplify some of my scripts - nice, I'll have to set aside some time.

The 1.8 sneaky peek has been going for some time, I expected it to be GA by now. Any idea whether it's getting close?
 
Quote:
Originally Posted by fudster View Post
The 1.8 sneaky peek has been going for some time, I expected it to be GA by now. Any idea whether it's getting close?
My gut feeling is that it is getting close. Recent changes seem to be mostly of the final-polish variety. I'd expect OF for iPad to ship first. Per the Omni blog, they're targeting a June 30 submission to Apple for that. I'm just guessing, but I'd expect a push to clean up and ship 1.8 in July.
__________________
Cheers,

Curt
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Applescript for dependent projects fudster OmniFocus Extras 10 2011-03-17 03:00 PM
Can't Get Through Initial 1st Sync & Now OF is Acting Odd. HappyDude Other WebDAV 4 2009-09-06 03:06 PM
.Mac and file saves acting weird since Leopard... dude OmniOutliner 3 for Mac 0 2008-03-05 09:30 AM
Can Omniplan do this? 10,000 projects / AppleScript isv OmniPlan General 3 2007-07-04 03:00 AM
AppleScript Gurus: Projects -> Notes BwanaZulia OmniFocus 1 for Mac 6 2007-06-21 11:02 AM


All times are GMT -8. The time now is 04:25 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.