1 Reply Latest reply on Feb 18, 2015 8:56 AM by johnrellis

    unknown keys when looking up photo:getDevelopSettings(keyname), etc.

    Judas Gutenberg

      i have some code that gets strings from a web server and in those strings are keys for looking up info from Photos.  the keys can be passed into

      photo:getDevelopSettings(keyname), photo:getFormattedMetadata(keyname), or photo:getRawMetadata(keyname) -- the problem is that sometimes these keys can be garbage or contain spelling errors (in some cases, even if they were harvested from the official Lightroom SDK docs) and they throw errors. what's the best way to check to see if the key being used for these methods is valid or, failing that, to intercept the errors that happen?

        • 1. Re: unknown keys when looking up photo:getDevelopSettings(keyname), etc.
          johnrellis Most Valuable Participant

          The most robust way, but also the most time-consuming, is to construct a dictionary of all the keys, using standard reverse engineering:


          - For getDevelopSettings(), take a test photo and set all of the options and sliders in the Develop panel to non-default positions, then dump the result of getDevelopSettings().


          - For get*Metadata(), start with the documented fields and write a test program that calls get*Metadata() on each field in turn to validate it. Then in the Metadata panel, for each tagset preset, fill in each field with a test value.  Then call getRawMetadata (nil) and getFormattedMetadata (nil) to dump out the keys, verifying each field value in the panel has been returned.  (In past versions, get*Metadata (nil) didn't always return all the keys, but that may be fixed now.)


          Constructing a dictionary ahead of time ensures you've got the best understanding of all possible keys,  A less time-consuming and less robust way is simply to catch errors using pcall:


          local success, result = LrTasks.pcall (function ()

          return photo:getRawMetadata (...) end)


          This approach is less robust because it can mask other sorts of errors, not just invalid keys.  But it may be the expedient choice.