3 Replies Latest reply on Oct 7, 2011 3:40 AM by arenol

    Filter Plugins, GUI and Apply filter (again) not working as it should?

    arenol Level 1

      I'm studying the StrokeFilter sample plugin code to determine the logic of its GUI interaction with the flash GUI extension.


      I have to say I'm a bit puzzled by this, and don't really understand why Adobe recommends implementing GUI using flash extensions; it doesn't fit in with the plugin-architecture.


      Once the user selects Object > Filters > SDK > Dash, a GetFilterParameters message is sendt to the StrokeFilterPlugin.


      The plugin then communicates with the flash GUI extesion to bring up the dialog.


      After the user has entered his parameters, and pressed the [OK] button, the OkClickedFunc calback function is called.  This function in turn makes the following call to the AINotifier suite:


      sAINotifier->Notify(kStrokeFilterUpdatePathNotifier, nil);


      This call cuases the Notify message to be sendt to the StrokeFilterPlugin. It is in the Notify method that the filter is applied to the selected paths.


      If I select another path and select Object > Filtes > Apply Dash, the same parameters should be applied to the selected stroke.  But (of course) nothing happens.


      When  Object > Filters > Apply Dash is selected, the StrokeFilterPlugin receives a GoFilter message, but this method does nothing.  Actually, since the plugin returns after the GetFilterParameters is sendt, the StrokeFilterPlugin recives the GoFilter message once the dialog is displayed, and of course long before the user has pressed OK or Cancel.


      This way, the entire GetParameters - GoFilter dichotomy of the plugin architecture is bypassed.


      Of course, this is a problem because there is no way you can, using many modern GUI libraries, set up a dialog to display and wait till the dialog is dismissed, (and then check out what the user pressed) like you could with the ADM.  Fore example the Cocoa [NSApp runModalForWindow] method returns imediately, not when the dialog is dismissed.


      Of course, it is possible to work around this problem by defining a variable that keeps track of whether a dialog is displayed or not, and then add this check in the GoFilter method.  Then you also have to remember the plugin parameters yourself. 


      But, wasn't the plugin architecture  supposed to take care of this?

      I guess you will encounter a simlar problem if you want to set up your filter to support actions(?).


      Therefore, I wonder what the recommended practice is, and whether the Illustrator Development team is planning to change this arhitecture to accomodate the callback philosphy of modern GUI libraries. Will that change recommended practice.



      Hoping that he doesn't have to do too much recoding for next release of AI