PITerminology.h vs PIStringTerminology.h

[electriciris]

Hi,

I noticed PITerminology is being phased out.  Correct?

I'd like to learn the correct way of using the strings defined in PIStringTerminology.h

As an example, I'd like to get a layer's name.   I had no problems doing this the old way, with PIUGet(classLayer, keyName, ....)

So, I found something called klayerNameStr  in PIStringTerminology.h and would like to use it to achieve the same thing.

I tried:

DescriptorTypeID runtimeKeyID;

error = sPSActionControl->StringIDToTypeID(klayerNameStr, &runtimeKeyID);

error = PIUGetInfo(classLayer, runtimeKeyID, ...)

But the PIGetInfo( ) failed.  What am I doing wrong? Obviously not getting the correct usage of klayerNameStr. ;-(

Also, just as a comment aside, PITerminology.h was a bit clearer to read, because there were prefaces to everything so they made sense, e.g

classLayer, classDocument,

vs

keyName, keyThis, keyThat

It was easy to know what was a class, key, enum, etc. and that helped show how to use them. Things have gotten, IMHO, slightly more confusing and unclear.

Anyway, thanks for any help

[Tom Ruark]

Yes, I liked PITerminology.h much better as well. You could skip that extra call to convert. The problem was the  'hash' codes had to be more and more obscure to be unique. The idea was that the four character code was somewhat human readable. The string versions are much better on the human readable front. But all in all it is just a key/value mapping so the key could be almost anything you want. You can look at AppleScript to see where the Actions system started from.

Ideally klayerNameStr is not actually needed. Every object (Layer, Document, Channel) would just have a name (keyName). This is why your code fails as there is no klayerNameStr entry on the layer object. There is a need in the 3D world to have such a key however. Some commands need this unique key and make it more obvious when coding.

What I do is look at Listener/Getter output vs looking at PITerminology and PIStringTerminology.

If you really want know which "stringVersion" matches which 'hash' version then I would do a reverse lookup of the "stringVersion" using typeIDToStringID("stringVersion") and see which ones do not have runtime IDS. Runtime IDS can usually be figured out by their low number when looking at them as numbers vs 4 characters.

Hope that helps.