I’m still on El Capitan, so probably that’s the issue there. Too many deadlines and ongoing development projects to take the time to upgrade right now.
More interesting things below, however. I finally got the push to work, but not pull, nor delete from the OmniJS side of the house. I also solved the error from earlier.
The primary issue above was that the document window wasn’t active (the console was), so it puked. That’s nice… from the OJS console, at least it doesn’t need to be active…or visible, but I guess the cleverness of JXA isn’t so clever. It’s worse than doing automated testing with QA Partner in the '90s where “window not found” was the bane of 24hrs of GUI automated testing… of course, it always happened 5 minutes after you left for the evening.
This is interesting, no?
document.windows.selection.canvas.background.userData.xfer shell delete document.windows.selection.canvas.background.userData.xfer true delete document.windows.selection.canvas.background.userData.xfer true document.windows.selection.canvas.background.userData.xfer shell document.windows.selection.canvas.background.userData.xfer = 9 9 document.windows.selection.canvas.background.userData.xfer shell
The “shell” value comes from this script:
app = Application("OmniGraffle");
app.includeStandardAdditions = true;
console.log("hidden? " + app.windows.visible());
console.log("minimized? " + app.windows.miniaturized());
console.log("can't delay in an interactive script; run it again now.");
// app.windows.canvas().canvasbackground.userDataItems.byName('xfer').value = "shell";
// app.windows.canvas().canvasbackground.userDataItems.byName('xfer').value = null;
And it appears that if I try and set a value on the OmniJS side, it never is visible to the JXA side, nor can I delete it from OJS.
Delete from JXA works, however.
At this stage, I’m just going to punt for now. I’ve wasted most of a day arsing around trying to exchange data, and if the window needs to be active (there’s too much of a delay for #activate to work), then it won’t really suit what I’m trying to do anyway.
I need a way that I can reliably poke OG from effectively a command line script run with
osascript so I can scrape the information there and not have to bundle a bunch of JS code into the plugin. I’m also not crazy about modifying existing code to fit the library module loading approach, and even then, it still makes it difficult to push out the results of the analysis in batch mode rather than interactively.
While this is pretty cool, and I now have a visualization tool I didn’t expect as a result of the last couple of days, if I’d gone ahead and just wrote a utility to parse the XML of the document directly (using libraries I’ve already written and proven in production for quite some time), I’d be more-or-less done with the original issue.
Much, much, much potential here, though, so will keep playing.
Oh, I know, I could generate text in a document and then automate the copy and paste to the clipboard with JXA and then figure out how to interact with the clipboard through the osascript command so that I could finally end up with the data I want in a nodejs world that I can do other, much more complex and interesting things with. ;)
Not today, methinks…
Thanks for all your help over the last couple of days, though. Really appreciate it!