The scripts are created in ExtendScript, essentially an augmented version of JavaScript. That means they are interpreted rather than compiled. There is no need to mess with include files or to link libraries. That should be a boon to those just getting started although they offer no benefit to experienced FDK programmers.
The FDK plugin development requires that you have the Microsoft Visual C++ development environment. To create scripts, you are likely to want to have Adobe's ExtendScript Toolkit. The ExtendScript Toolkit is easier to get started with but does it provide sufficient support for debugging? For now, I leave this unanswered. (I need to do some more heavy duty development work before I make a judgment.)
What about the code? Here is Adobe's "Hello World!" written in ExtendScript:
Alert("Hello World!", 1); /* FM Alert With OK and Cancel buttons */
Here is the same program written for the FDK:
VoidT F_ApiInitialize(IntT init)
{
switch(init) {}
case FA_Init_First:
F_ApiAlert((StringT) "Hello World!", FF_ALERT_OK_DEFAULT);
break;
At first glance, ExtendScript wins the ease of use battle hands down. (All that extra FDK code is telling FrameMaker that the alert should appear before FrameMaker shows itself to the user. The alert box produced has OK and Cancel buttons with OK as the default choice.)
Will this advantage hold up in the face of more complex programming tasks? That is the $64,000 question. In future posts, I will be taking common FDK programming paradigms and rewriting them in ExtendScript. With a few of those under my belt, I will have a more informed opinion.
No comments:
Post a Comment