6 Replies Latest reply on Nov 13, 2014 10:19 AM by cchimi

    Documentation of ScriptUI window.update()?

    cchimi Level 2

      Does anyone know if this function is documented? I'm trying to implement a progress bar similar to the one Marc Autret supplies here: Re: Type of window for progress bars?

       

      In general it is awesome and works well. The one problem I have is that I want to be able to change a statictext label as the progress bar moves along. When I do this, the statictext loses its centered justification. The only thing I've found that is even close to helpful is that when I apply the mysterious .update() function, the label will rejustify itself -- but only for a second. I thought if I could read about the nuts and bolts of what this does, I might be able to work out a solution.

       

      It's a minor aesthetic thing, but I would really like to understand it.

       

      My hit function, where the problem occurs:

       

      this.hit = function(msg) {
           st.text = msg || st.text;
           w.update();\\Causes the window to flicker; you can tell that the text is justifying to center and then moving back to the left.
           ++pb.value;
      };
      
      
        • 1. Re: Documentation of ScriptUI window.update()?
          Dirk Becker  Level 4

          There is a way to force the layout manager to recompute.

          Something like window.layout.layout() - I think it is mentioned in the javascript tools guide.

          • 2. Re: Documentation of ScriptUI window.update()?
            Marc Autret Level 4

            Hi cchimi,

             

            Regarding Window.update() here are some details:

             

            [ScriptUI]  Window.update()

            Allows a script to run a long operation (such as copying a large file) and update UI elements to show the status of the operation. Normally, drawing updates to UI elements occur during idle periods, when the application is not doing anything and the OS event queue is being processed, but during a long scripted operation, the normal event loop is not running. Use this method to perform the necessary synchronous drawing updates, and also process certain mouse and keyboard events in order to allow a user to cancel the current operation (by clicking a Cancel button, for instance).

             

            During the update() operation, the application is put into a modal state, so that it does not handle any events that would activate a different window, or give focus to a control outside the window being updated. The modal state allows drawing events for controls in other windows to occur (as is the case during a modal show() operation), so that the script does not prevent the update of other parts of the application's UI while in the operation loop.

             

            Anyway I strongly doubt you reach any satisfactory enhancement using either w.update() and/or w.layout.layout()—on the AutoLayout manager algo, my investigations here: http://indiscripts.com/blog/public/LayoutManager-Draft.pdf

             

            But here is the promising fact: reassigning StaticText.location is much faster than any other approach. So one can manually center the message—keeping the statictext left-justified—by simply repositioning the control with respect to the width of the text. That can be done on the fly using StaticText.graphics.measureString(newText). Give a look at the new implementation of my ProgressBar snippet to see how it works:

            Re: Re: Type of window for progress bars?

             

            My tests provide good results (so far) on various ID versions from CS4 to CC.

             

            @+

            Marc

            • 3. Re: Re: Documentation of ScriptUI window.update()?
              Loic.Aigon Adobe Community Professional

              Hi,

               

              I can just second Marc on this one. I no longer rely on any internal layout mechanisms. I on the contrary redraw the UI everytime I need it with a dedicated function :

               

              var UI = {
              
              
                   resizeItem:function(item, w, h, x, y ){
              
                if ( w!=undefined ){ item.size.width = w;}
                if ( h!=undefined ){ item.size.height = h;}
              
                if ( x!=undefined ){ item.location.x = x;}
                if ( y!=undefined ){ item.location.y = y};
              
                },
              }
              

               

              Then I am sure what I get

              • 4. Re: Documentation of ScriptUI window.update()?
                TᴀW Adobe Community Professional & MVP

                That seems a little risky to me. How do you test what size font the

                operating system is set to? Some people enlarge their OS fonts -- 125%

                or more.

                 

                Or on a retina display, pixels are tiny. How do you account for that?

                 

                If you rely on Adobe's layout manager, then I guess (presume) that they

                have accounted for all these things.

                 

                I suppose you have to do a lot of string measuring, like in Marc's example?

                • 5. Re: Documentation of ScriptUI window.update()?
                  Loic.Aigon Adobe Community Professional

                  Hi Ariel,

                   

                  So far I use this with relative dimensions based on the main window size. Maybe it's not 100% reliable given strings length issues but I have found it stronger than calling layout.layout() and having everything messed up.

                  I created a rich list where list items where groups of ui items in ScriptUI and the only way I could get a solid and constant display was to manually layout the components.

                   

                  FWIW,

                   

                  Loic

                  • 6. Re: Documentation of ScriptUI window.update()?
                    cchimi Level 2

                    That's interesting, thanks. I will definitely give that a try. And, by the way, thanks for posting the original script; it really helped me to understand how one might implement a progress bar like that. I tried to tag you in the original post but for some reason your name wouldn't come up.

                     

                    And thanks to the other posters for the discussion. I think I'm trained at this point not to futz too much with the layout, but in this case it might make sense.