photo:getPropertyForPlugin( _PLUGIN, 'myProperty', true )

[areohbee]

no-throw parameter seems more like a no-op.

Always throwing an error if the property not found, regardless of 3rd parameter (noThrow).

Anybody else?

Rob

[Guest]

Why care? Don't use that param and it behaves like pre Lr 3 and throws.

It is good to have a way to peek at a property without committing. I assume this tweak was made in response to a specific need by consumers of the SDK.

[areohbee]

As long as you know how it behaves, its manageable. Its when you assume it works as advertised that you can get into trouble...

No throw:

local status, message = LrTasks.pcall( photo.getPropertyForPlugin, photo, _PLUGIN, 'myProperty' ) -- works for Lr2 and/or Lr3.

Whereas:

photo:getPropertyForPlugin( _PLUGIN, 'myProperty', true ) -- works for neither one, or so l've concluded...

My purpose in posting:

1. Sanity check - is it really completely broken, or did I come to a wrong conclusion?

2. If my conclusion is correct, a warning to other plugin authors: beware...

Rob

[Guest]

Sure, they added a sanity check that doesn't break old code unnecessarily. If you want SDK 3.0 behaviour, ideally it is because you read the 3.0 SDK...

I'm actually not sure of the distinction you are trying to make.  All they did was add another param for 3.0, right?  So, if it is missing or false, default to the 2.0 behaviour.  This seems reasonable to me.

[areohbee]

The problem is: Its broken.

Even if I say "Dont Throw" (by passing 'true' without the apostrophes as the third parameter), it throws!!!

Does it seem to work as advertised (as documented) for you? - Not me...

Rob

[Guest]

Ah, I wasn't able to decode your original post on initial reading.

Isn't noThrow the fourth param? Or are you specifying the noThrow by name?

[areohbee]

How embarrasing - no wonder it wasn't working.

Yes: 4th parameter, not 3rd!!!

Duh,

PS - How to delete this thread???

Thanks,

Rob

[pact_software]

Did you try getPropertyForPlugin with just one parameter?

According to the SDK help it should return a table of the available metadata fields. For me it crashes.

Anyone an idea?

Paul

[areohbee]

I dont think getPropertyForPlugin has been programmed to return the whole set.

For me, I get an error message like: "Unable to get property 'nil'..."

(it doesn't crash though, i.e. pass noThrow as the fourth parameter and it will return the error message instead of throwing)

PS - getRawMetadata will return the whole set, as documented.

Perhaps you could submit a bug report to either fix the method or update the document, eh?

Rob

[johnrellis]

getRawMetadata will return the whole set, as documented.

That doesn't seem to be true in my tests -- catalog:batchGetRawMetadata (photos, nil) doesn't appear to return the following:

countStackInFolderMembers, countVirtualCopies, durationInSeconds, isInStackInFolder, isVirtualCopy, keywords, masterPhoto, stackInFolderIsCollapsed, stackInFolderMembers, stackPositionInFolder, topOfStackInFolderContainingPhoto, virtualCopies

It may be that batchGetRawMetadata (nil) will return some of these fields if they have non-default values, but at least for the stack-releated fields, they never get returned by batchGetRawMetadata (nil), even if a photo is in a stack.

With catalog:batchGetFormattedMetadata (photos, nil), I've found just one field that isn't returned:

folderName

[areohbee]

Thanks John,

I've never tested for completeness.

[johnrellis]

I think the working rule is to pass the list of all the fields you expect to get back.

[DawMatt]

Hi John,

I haven't verified what you've posted above but from memory I've never seen those fields returned by the batchGet.. methods either.  Have you ever seen them returned when you explicitly request them?

Have you logged a bug for this?  I have a plugin that could really use these from the batchGet... methods so I'll test this and log the bug (as well?).

Thanks,

Matt

[johnrellis]

Have you ever seen them returned when you explicitly request them?

Yes, I believe every documented field is returned by batchGetRawMetadata() and bachGetFormattedMetadata() when you pass it explicitly. LR 3.0 had a bug that would raise an error if you passed some of the documented fields, but it was silently fixed somewhere between 3.0 and 3.3 (no announcement in the release notes).

[DawMatt]

Hi Paul,

pact software wrote:

Did you try getPropertyForPlugin with just one parameter?

According to the SDK help it should return a table of the available metadata fields. For me it crashes.

I just checked the API reference, and it indicates the second parameter of catalog:getPropertyForPlugin( plugin, fieldId ) is required.  So while it would be more consistent with the get...Metadata methods of LrPhoto if it acted as you described, it seems to be operating as documented. Maybe you could submit a feature request for this to be changed?

Thanks,

Matt

[pact_software]

Thanks for the feedback. It seems to be just a little error in the documentation.

I didn't know about the batchGet functions, but they did the trick for me. I needed to get access to an plugin property that was set in lightroom 1 and 2 using a now deprecated (and no longer working function in lightroom 3). The batchGetRawMetadata call for CustomMetadata did the trick.

thanks,

Paul

[areohbee]

Matt,

I never got catalog:setPropertyForPlugin to work at all - did you say that worked for you?

I wonder if that got fixed in a recent release or if I/we made some other blunder else-thread (multiple people tried to no avail...)

Anybody else?

Rob

[DawMatt]

Hi Rob,

I've never had a reason to try the setPropertyForPlugin() method, so can't comment on its usage.  I just quickly checked the API Reference re Paul's question because I've noticed the SDK query methods are a little inconsistent around whether a nil value is an error or an indicator to query all available values.

Thanks,

Matt

[areohbee]

Hi Matt,

I wasn' sure if you realize there are two functions:

1. photo:getPropertyForPlugin

2. catalog:getPropertyForPlugin

This thread was originally about the former, but then you introduced the latter - got me confused...

My experience:

- The former (photo method) says you can use nil for name, and that works, subject to limitations John mentioned.

- The latter (catalog method) is completely broken. (has the catalog method worked for you???

Rob

[DawMatt]

Aah. My mistake.  Sorry for the confusion.

@Paul, Now Rob has pointed me at the right class I can see the doco issue you stumbled over.  The field parameter is mandatory but the description of the return values indicates it is not.  So it looks like they need to clean up the return value information and then the doco would match the design/implementation.

@Rob, I'll need to do some testing now to verify this LrCatalog method misbehaviour you have mentioned.  Sounds ugly.  Have you reported those bugs yet?

Matt

[areohbee]

HI Matt,

The catalog:getProp... bug has been officially reported, I *think* (sorry for being such a flake). I did not report any anomalies in the other methods.

Rob

[areohbee]

Although I had the position of the no-throw parameter wrong, in the thread title, I just received an error when no-throw was true (4th parameter)

To recreate:

Make tight loop reading photo property, then delete the photo.

My original bug report stands - am reporting to Adobe now...

Rob