[SCRIPT] Missing scrollbar

Hi Luis Felipe,

ScriptUI CS / CC are so different in behavior, component support, event cycle and bugs (!) that it is practically impossible to tell why something seems to work in one environment and not in the other. (Anyway I doubt your code works so well in CS6 either, at least in a cross-platform approach.)

The nesting of functions, UI components and event handlers is hard to analyze from the outside, so that I would have difficulty in determining what is strictly wrong in your code. That said, I can hazard a few guesses:

0. First of all I don't quite understand the point of using two modal windows while the same scenario could in principle be obtained from a single component.

1. It looks like a bad idea to call the 2nd function, myNW(), from within the b3.onClick handler that just closed the first Window. Have in mind that b3 still belongs to wo — even after wo.close(2) — which makes the caller b3.onClick also remain within the lifecycle of wo (a kind of “vanishing object”) while myNW() is invoked. Although wo is assumed to be closed at that very moment, it has to retain an internal memory area within which the entire next stage must take place. Thus it would be probably much safer to change the lines

    b3.onClick = function ()
    {
    wo.close(2);
    myNW();
    }

    // . . .

into something like

    b3.onClick = function ()
    {
    wo.close(2);
    }

    // . . .

    if( 2===wo.show() ) myNW();

2. Using the first sheme above, I suspect that the internal LayoutManager object remains stuck to wo (the vanishing Window), at least in CC. This means that statements like nw.layout.layout(1) may still operate behind the scenes “with wo in mind”, which makes updating the UI completely erratic. A good clue to this issue is that with a 4K display in Windows10/InDesign CC, the nw Window moves across the screen each time nw.layout.layout(1) is invoked. We know from this bug report that this symptom reflects a “UI scaling” bug in ScriptUI CC when size, preferredSize, location, bounds or windowBounds properties are involved, using screen coordinates vs. ScriptUI coordinates in a mixed way. The fact that the Window nw changes its own screen location in such an environment indicates that it might somehow depend on a higher level object (namely the original Window wo!) when nw.layout.layout(1) is innocently processed. Since the real container to be updated is the pFix panel, maybe the code pFix.layout.layout(1) would be more targeted & less confusing (?)

3. Continuing from the previous point it's usually a good idea to assign a distinct title to Window components — var nw = new Window("dialog","title1"), etc — because we have good reason to believe that it helps ScriptUI to distinguish between internal references. I can't prove this argument but I wouldn't be surprised if the LayoutManager behaved differently if your more-or-less-nested Window instances had a distinct, specific title.

4. Finally, it should be remembered that the LayoutManager relies on an extremely fussy algorithm that handles preferredSize properties (always the best option!) quite differently from those that explicitly set the size/position/bounds of your UI components. (Things get even more complicated when 'fill' alignments are involved.)

I haven't had time to thoroughly test these few ideas, but I think suggestion 1. is the most decisive. Hope that helps!

Best,

Marc