7 Replies Latest reply on Mar 25, 2016 11:35 AM by Laubender

    Readonly Properties





      I want to know How can I detect readOnly properties.



        • 1. Re: Readonly Properties
          Loic.Aigon Adobe Community Professional

          I can't see any information about writability of a property. But if you think your code could hit such a scenario, it's likely that a try/catch instruction will help.

          • 2. Re: Readonly Properties
            Marc Autret Level 5



            The ReflectionInfo structure has a type property (string) that can take one of the following values: unknown, readonly, readwrite, createonly, method or parameter.


            So technically something like myObj.reflect.find(myPropName).type should enlighten us. However I seem to remember that the result is non reliable with DOM objects (?)

            Not sure I used it the right way…




            • 3. Re: Readonly Properties
              Laubender Adobe Community Professional & MVP

              Hi Marc,

              just tested your suggestion on a selected rectangle.

              The result was promissing.


              // Rectangle selected.
              var myObj = app.selection[0];
              var myPropName = "fillColor";
              // Result is a String object:
              // readwrite


              However, I cannot know, if this is working on every object and property.

              Thank you for the tip.



              • 4. Re: Readonly Properties
                Laubender Adobe Community Professional & MVP

                And this test is no proof if a property can actually be used.


                If you test a selected RGB JPG image placed, you'll get back "readwrite" for "fillColor".
                But you'll get an error—"Property not supported"—if you e.g. ask for myImage.fillColor ;

                just to mention a particular case.


                For all the lurkers: Why? See here:

                Re: Grouped objects fill color


                So the question is: What do we actually gain, if "readwrite" is returned?
                I think, you'll get what's defined per se in the constructor of the class.

                Ok, the OP is asking for "readonly" and there the case and its implications should be more clear.



                • 5. Re: Readonly Properties
                  Laubender Adobe Community Professional & MVP


                  Or not.


                  If I'm asking for "effectivePpi" for a selected image, the method also comes back with a "readwrite".
                  And that is not ok. "effectivePpi" of an image object would never be a "readwrite" property. At least the DOM documentation is suggesting this.





                  • 6. Re: Readonly Properties
                    Marc Autret Level 5



                    I'm almost certain that the Reflection tool has absolutely no knowledge of DOM "runtime" issues. Things are probably just hard-coded as in the Dictionary API. Also, since Reflection and ReflectionInfo belong to the ExtendScript core they can only reach the formal description of objects and properties. I think it's crucial to keep in mind that, by contrast, interacting with the DOM is mostly based on deferred commands (specifier resolution mechanism, etc). Those commands travel through special beasts known as LiveObjects which, as we all know, do not behave as simple JS objects. The best illustration of this is the famous everyItem() method and the plural verb-first command we trigger from it. You may also observe that as soon as you hit a simple DOM enum such as SpecialCharacters.THIN_SPACE, the related constructor suddenly wakes up as [[enumerable]] in the global space:


                    alert( $.global.hasOwnProperty('SpecialCharacters') ); // => false
                    SpecialCharacters.THIN_SPACE; // 'hit' command
                    alert( $.global.hasOwnProperty('SpecialCharacters') ); // => true


                    These are just examples of the special way ExtendScript encapsulates the DOM infrastructure. Therefore there are really two distinct levels to consider when we are checking the behavior of our code, on one hand the formal JavaScript stuff in itself (involving the usual rules we know, object references, dependencies, prototypal inheritance, and so on), on the other hand the command that is actually sent, at runtime, to InDesign. It is only at that moment that things happen—if they successfully happen!—and many objects/properties can be deeply impacted in return. Examples: a specifier is then resolved, a PageItem then becomes a TextFrame, an Oval is then coerced to a Polygon… or some formal property that was assumed available unexpectedly protests, "No, in fact I have no meaning in the current state of affairs!"


                    At best, Reflection can tell us what is statically right, but there is every reason to believe that it will remain blind to live issues I've just mentioned.




                    • 7. Re: Readonly Properties
                      Laubender Adobe Community Professional & MVP

                      Ah yes, of course.

                      Thank you for reminding me about this.
                      You elaborated this all already somewhere on your website, I think.