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.
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…
just tested your suggestion on a selected rectangle.
The result was promissing.
// Rectangle selected. var myObj = app.selection; var myPropName = "fillColor"; myObj.reflect.find(myPropName).type; // Result is a String object: // readwrite
However, I cannot know, if this is working on every object and property.
Thank you for the tip.
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:
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.
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.
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
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.
Ah yes, of course.
Thank you for reminding me about this.
You elaborated this all already somewhere on your website, I think.