Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I have annotation where a single annotation feature consists of one or more TextElements and RectangleElements grouped together in a GroupElement and then stored in the annotation feature. To edit the contents of the annotation feature later, it would be nice to be able to know which elements are related to each other. The elements have natural groupings, but those groups cannot be grouped together and then grouped into the final GroupElement for storage. Due to a bug, the ESRI optimized map service cannot handle nested groups in annotation. (See this posting.) So all elements just have to be thrown in together. An identifier object, holding, say, a group name string, attached to each element would make identification of elements belonging to each subgroup much easier to identify. The Avenue ObjectTag object in old ArcView GIS 3.x (I guess it was a property) used to be great for such things. You could stick a tag on just about any object in the whole model, including dialog controls. Really handy. I haven't thought about this -- until recently -- since the old Avenue days, but it has now come to my consciousness again. I haven't been able to find anything like the old ObjectTag in ArcObjects. Any ideas?

share|improve this question
1  
Did you try using IElementProperties.Name for this purpose? –  blah238 Mar 29 '13 at 18:26
    
@blah238 - No I didn't. Darn. How did I miss that one? Duh. You save me once again. Thanks. (Hanging head in shame) –  celticflute Mar 29 '13 at 18:38
add comment

1 Answer

up vote 2 down vote accepted

I guess the most direct equivalent in ArcObjects would be IElementProperties.CustomProperty:

CustomProperty is a place for developers to attach custom objects to an element. Previous versions of the software required that the specified variant be of type VT_UNKNOWN, i.e. a reference to an object, but that requirement has since been removed. Now, the CustomProperty can also be a simple type like an integer, double, boolean (VARIANT_BOOL) or a string (BSTR).

When this property is an object reference, the object must implement a persistence interface, so if you write a custom object it must implement IPersistStream or IPersistVariant. As an alternative to writing a custom object, you can use a PropertySet or XMLPropertySet, since they both already implement IPersistStream.

CustomProperty is never used by the core ArcObjects for its own elements, but the core software will expect to find an IPersistStream or IPersistVariant interface when the this property is an object reference, and it is part of an element being retrieved from or stored in an .mxd file.

share|improve this answer
    
Thanks again. This is just what I had in mind ... and more. I am prototyping in Python/comtypes/ArcObjects at the moment, so the Name populated with a string will do fine for now; however, all of this is going into .NET eventually, and we may want to do something more sophisticated. –  celticflute Mar 29 '13 at 18:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.