I suppose this could be done through BridgeTalk - but is there an easier way to have an ExtendScript function call a method in the new CS SDK? (Flash Builder)?
This might simplify porting a large amount of code that's js. Also, it seems unless you do a C++ plug-in you don't have control over the menus.
Thx
The easiest way is to define a function in your ExtendScript script like:
var __controller = {};
initWrapper = function( wrapper ) {
__controller = wrapper;
}
Then, you can make a call from an ActionScript object like:
var esi:HostObject = HostObject.getRoot( HostObject.extensions[ 0 ] );
esi.initWrapper( this );
Then, in ExtendScript, you can directly call AS functions on that object via the __controller reference.
James
Yes, just got an email from James that all made it back. We were wondering how it would go with the announcement about no flights to the IK on Saturday.
Twas great to meet you. We never did get a lot of time to talk. I certainly hope the stuff you were doing to grow your business helped!
Bob
Harbs. tactfully suggested:
Our buddies from the UK are finally managing to get home? (I've been thinking about them...)
Harbs
I've managed to find out what I needed to know. First up, the menus...
We have some libraries being added to the SDK soon. Soon enough that I wouldn't suggest bothering to do it on your own.
As for calling from ExtendScript - I want to ask why you think you'll need to do that. Is it the porting process?
It's really not as difficult as it seems at first. If you keep type checking turned on, you'll need to add type information to ExtendScript, and you'll need to set up an "app" analog. The cswa libs use "InDesign.app" instead of app, so if you have:
public var app: Application = InDesign.app;
as a public var in your class, it will solve that one.
You can turn off type checking and pretty much just paste your ES code (so long as you have "app" defined). If you keep type checking on, it'll show you where all the issues are (usually those will just be warnings, not errors). Granted it takes time, but it's not difficult.
There's a couple of other gotchas, like this one :
var doc: Document = InDesign.app.activeDocument; // to set context of "doc"
ALWAYS USE:
var frame: TextFrame = doc.textFrames.item( 2 );
NEVER USE:
var frame: TextFrame = doc.textFrames[ 2 ];
The bracket notation will fail. Remember that for InDesign's various collections (documents, textframes,pageitems, etc).
Bob
Bob,
Great info - I'll definitely wait for the library. I'm sure it will be ready before I am.
The reason is that we have some code from another developer that we licensed that is in ESTK. Most of my code is all of the UI code. Moving this to Flash/Flex will greatly improve things.
Right now the code works both ways - my UI calls some of the ESTK code (which seems pretty easy to do). However, the third-party code also has some event handlers which call back into my code. I think in the long run moving both of our code to the new environment will solve many issues. I was just going to see if it was possible to move just the UI portion first.
Thanks again.
Brad
Ah...
The coming library will give you access to ID's events, and hence menus.
As we're talking about interacting back to a UI, you're going to want to port that 3rd party code. Interacting with a Flex UI from ExtendScript, while possible, would be architecturally wrong, and would take significant effort. Possibly more than doing the port itself. I would go ahead and take the pain now.
Bob
For your reading pleasure, we've recently posted a cookbook entry which goes into detail on communicating between the CS SDK and ExtendScript. Check it out here: http://cookbooks.adobe.com/creative_suite_sdk. Also, feel free to add a recipe of your own.
North America
Europe, Middle East and Africa
Asia Pacific