[amorya]

I'm using the Scripting Bridge to control OmniFocus. If I write this code:

			for (OFTask *task in project.rootTask.flattenedTasks)
			{
				NSLog(@"Task %@", task.name);
			}

I get a crash. "project" is a valid OmniFocus project (I can log its name etc). Calling "project.rootTask" works fine. But when I ask for "flattenedTasks", I get this crash:

2012-07-07 15:17:27.635 OmniReviewer[18623:403] -[SBObject classForCode:]: unrecognized selector sent to instance 0x7fd539607ea0

The same thing happens if I just ask for "tasks" rather than "flattenedTasks".

Does anyone have any idea why I can't seem to get the child tasks of a task?

Have you tried project.flattenedTasks ?

(The root task of project is a rather strange and special case, it is really a reference to the project itself – A project is just a decorated task)

[amorya]

Sadly, there's no such property. The only things that have a "flattenedTasks" property are tasks and documents.

The comment for the rootTask property of a project says "The root task of this project, holding the project's name, note, dates and child tasks.", which is what led me to think you're meant to do it that way.

Curious ...

That's not what theory would predict – you can certainly access the flattened tasks of a project through the Applescript dictionary ...

--

A full llist of the classes from which flattened task elements can be accessed:



--

[amorya]

It's odd: the Scripting Bridge thing that generates headers didn't generate any "tasks" property on "project".

So I tried doing it manually:

SBElementArray *arr = [project elementArrayWithCode:'FCac'];

Sadly that gave the same error as I was originally experiencing :(

A summary to be found in this interesting thread (to which Ken Case recently contributed a perspective), is that Scripting Bridge is:

"fundamentally defective by design and breaks to some degree or other on pretty much all apps"

As you will read in the thread (if you haven't seen it already), all of this kind of non-Applescript scripting is getting increasingly fragile at the moment. The Ruby route described there by Matt Neuburg (fetching the dictionary through sdef instead ascr/gdte) seems to be the most robust for now (apart from Applescript itself).

https://github.com/mattneub/appscript
http://www.apeth.com/rbappscript/00intro.html

It's still not clear what the mid-term effects of sand-boxing on the scriptability of OS X will really be. To quote the phrase used by Matt Neuburg, again in that thread, it may still be a bit early get too "happy-clappy" about the impact of sandboxing on automating work-flows and integrating apps into larger tool-chains... )

--

[amorya]

I sidestepped the problem!

If I do

[[rootTask propertyWithCode:'FCft'] get]

rather than doing elementArrayWithCode, it works and returns me an array of tasks. The latter causes the crash, and that seems to be what the auto-generated headers were doing.

[amorya]

Just in case anyone was following along at home, I believe this was an Apple bug and is fixed in Mavericks.