The Omni Group Forums

The Omni Group Forums (
-   OmniFocus Extras (
-   -   Scripting bridge: crash when trying to get child tasks of a task (

amorya 2012-07-07 07:18 AM

Scripting bridge: crash when trying to get child tasks of a task
I'm using the Scripting Bridge to control OmniFocus. If I write this code:

[CODE] for (OFTask *task in project.rootTask.flattenedTasks)
NSLog(@"Task %@",;

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:

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

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?

RobTrew 2012-07-07 08:09 AM

Have you tried [I]project.flattenedTasks[/I] ?

(The [I]root task[/I] 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 2012-07-07 08:17 AM

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.

RobTrew 2012-07-07 08:25 AM

2 Attachment(s)
Curious ...

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


RobTrew 2012-07-07 08:40 AM

1 Attachment(s)
A full llist of the classes from which flattened task elements can be accessed:



amorya 2012-07-07 10:14 AM

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

So I tried doing it manually:

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

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

RobTrew 2012-07-08 01:12 AM

A summary to be found in [URL=""]this interesting thread[/URL] (to which Ken Case recently contributed a perspective), is that Scripting Bridge is:[INDENT][I]"fundamentally defective by design and breaks to some degree or other on pretty much all apps"[/I][/INDENT]
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 [I]sdef[/I] instead [I]ascr/gdte[/I]) seems to be the most robust for now (apart from Applescript itself).


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 [URL=""]that thread[/URL], 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 2012-07-08 03:48 AM

I sidestepped the problem!

If I do

[CODE][[rootTask propertyWithCode:'FCft'] get][/CODE]

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 2013-11-10 06:00 AM

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

All times are GMT -8. The time now is 02:13 AM.

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