ScriptUI reactivity difference

[DBarranca]

Hi,

I'm having some hard debugging time. I can't post the full code here, but basically what is driving me nuts involves ScriptUI reactivity difference; the scenario, to the best of my understanding, is as follows.

I've a ScriptUI 'dialog' Window with sliders; slider's 'change' callback triggers an image processing routine.

The user goes through the process of tweaking the few sliders, waiting for the routine to be completed, evaluating the result, tweaking again, and so on and so forth until he's happy with it and calls quit.

I've done my best to disable the GUI as soon as any single slider is dropped, so that the routine has the time to complete and multiple calls won't overlap. The GUI is then re-enabled again, then app.refresh() and user is able to move the sliders again. That is:

1. User drag slider -> slider 'change' ->

2. slider disabled, app.refresh() ->

3. routine runs ->

4. slider re-enabled, app.refresh() ->

back to 1.

The user can start dragging as soon as the slider is re-enabled (as quickly as he can), because the routine is certainly done.

Everything goes as expected as long as the script is run from ESTK, (targeting PS CC2014, OSX).

As part of my building process, I add the needed <javascriptresource> and put the file in the Presets/Scripts folder, in order to make it appear under the Filter menu (which is where my scripts usually belongs, with no problems at all).

Now, the weird part is that the very same script, with the only difference of the <javascriptresource> part, when called from the Filter menu for some reason I cannot absolutely get breaks somewhere with errors that to the best of my understanding I have been able to track back to overlapping calls of the slider.

That is, it seems like that, when the GUI is re-enabled, either the routine is not actually completed and/or the scripting engine needs a couple of extra seconds of pause to recover and react again: in fact (only when the script is called from the Filter menu) if the user is too quick and slides the slider as soon as it gets enabled again, errors (due to vars not found etc) are fired.

Conversely if you run it from ESTK, you can be as fast as Flash Gordon and the slider does his job flawlessly (I'd say: as expected, since if it is re-enabled, by definition it is ready to operate again).

Any help is really appreciated - I would tag Tom Ruark‌, he might possibly suggest something to preserve my mental health 🙂

Thank you very much,

Davide Barranca

---

www.davidebarranca.com

www.cs-extensions.com

[DBarranca]

Further testing (which led nowhere) makes me suppose that the weak point is the slider callback, which takes unexpectedly too long to return.

Simplifying my actual code:

var myRoutine = function() {
  disableGUI();
  // does image processing stuff
  enableGUI();
}

var sliderChangeCallback = function(event) {
  myRoutine();
}

mySlider.addEventListener('change', sliderChangeCallback);

l've instant, visual feedback of the sliderChangeCallback return, because the GUI is enabled. At least this is what I thought.

If you add an alert at the end of the callback, such as:

var sliderChangeCallback = function(event) {
   myRoutine(); // disableGUI, image processing, enableGUI
   alert(app.activeDocument); // for testing purposes only
}

There is a *noticeable* delay between the moment the GUI gets re-enabled (that is, myRoutine's return) and the firing of the alert - between one and two seconds.

What I've repeatably tested is that, under the circumstances described in my original post (i.e. when calling the script from the Filter menu and not ESTK, and dragging the slider as soon as it gets re-enabled without any wait) the error that fires is... app.activeDocument being undefined!

This really puzzles me.

By the way, it makes no difference to move disableGUI and enableGUI functions inside sliderChangeCallback.

Davide

PS

it seems the late and lamented Mike Hale run into that back in 2011 - app.refresh() being async? Re: Script ui - Slider issue-somthing strange...

[DBarranca]

After lot of nocturnal head-scratching time, *it seems* I've come up with a solution - basically I've got rid of app.refresh and used the WaitForRedraw function instead:

WaitForRedraw = function() {
    var d;
    d = new ActionDescriptor();
    d.putEnumerated(stringIDToTypeID('state'), stringIDToTypeID('state'), stringIDToTypeID('redrawComplete'));
    executeAction(stringIDToTypeID('wait'), d, DialogModes.NO);
};

As far as I know, WaitForRedraw is what's been used before app.refresh got implemented - see Mike Hale hypothesizing its async behaviour in the link mentioned above in this thread)

Also, I've moved right in the callback the GUI toggling:

var sliderChangeCallback = function(event) {
   disableGUI(); // using WaitForRedraw instead of app.refresh()
   myRoutine();
   enableGUI(); // using WaitForRedraw instead of app.refresh()
}

This way, apparently (still have to stress-test it) the slider becomes responsive as it should be.

Nonetheless, I don't understand why launching the old script via ESTK as opposed as from Photoshop makes any difference in this callback behaviour.

Davide

[matias.kiviniemi]

I guess you found an answer, but some things I've done in the topic that might or might not be helpful

• add a check to your event handlers if it's already being processed (especially if you trigger something async). I think I diagnosed that in some cases events queue up in Photoshop/ESTK side and handler gets called multiple times in succession. Same thing applies for disabling, i.e. not depending on the component to actually get disabled but just stop processing stuff
• had problems that a progress dialog with cancel-button had different behaviour in Win & Mac with Windows failed to redraw a dialog and Mac failed to catch a cancel-button click. After some experimenting added following to each progress update
  $.sleep(50)
  dialog.update()
• Use a timer to delay certain operations to allow refresh.
• Make things async, i.e. don't call the script in an event handler but mark it to be called in the next convenient moment