[CE C# comAPI] get Attachment Slot (ger. "Pos.") number

Hi,

PatB said:

In the MicroStation Attachment Dialog is a column "Pos."

I do not see anything like "Pos." column in MicroStation (tested with CE U16).

Do you mean "Slot" value, displayed in References dialog?

Or, can you provide a screen capture to explain what "Pos." do you mean?

PatB said:

which is like a unique ID for each Attachment.

Reference slot is unique (different attachments cannot use the same slot), but not static (a user is able to change the slot number).

PatB said:

Where/how can i get access to this number/ID in the comAPI for CONNECT?

In general, I guess there are 2 ways:

• To call proper MDL function to obtain this attachment parameter.
• To use PropertyHandler to access the slot value.

PatB said:

I can't use the new .NET API since the code has to work in v8i and CE.

It's not recommended to write code both for V8i and CE.

Personally I treat it as bad idea, because my experience is that in long term perspective, it leads to more bugs/issues, very limited functionality in CE and higher maintenance cost. And ti even cannot be the same code, because V8i target is 32bit NET Framework 3.5, whereas CE target is 64bit NET Framework 4.6.

PatB said:

Is there another way to get a unique ID for an attachment?

Why do you need this information? As far as I remember, the reference slot is maintained for backward compatibility only (this feature comes from something like MicroStation V4 era) and has no real usage in V8i or CE.

Regards,

  Jan

ah yeah, it's "Slot", the german dialog shows "Pos." (a case of unlucky translation, since "Slot" works in german too)

I write a program which selects an element, stores its ID in a tag and later needs to find that exact element again.

Saving the ElementID only obviously isn't enough, so i need a sure way to identify the attachment to which this element belongs to.

Saving the entire path+filename of the attachment doesn't work either, since i fear this text is way too long to store in tags (which Bentley most likely has as a fixed length char-array internally and causes a crash when you give it a longer string, and i don't feel like finding out the length limit and writing a secure function to set the tag value with a shortened string).

Can you provide the name of the MDL Function to get the Slot number?

PatB said:

I write a program which selects an element, stores its ID in a tag and later needs to find that exact element again.

In such case, you cannot use slot in my opinion, because it can be changed by a user directly from GUI (or by any other application, that, typically from historical reasons, use slots too).

PatB said:

Can you provide the name of the MDL Function to get the Slot number?

I am not sure, it would be probably some from mdlRefFile_get*Parameters. For details, you have to check both V8i and CE C/C++ documentation.

But, when it is used, the code is automatically split into V8i and CE versions, because to call native C functions requires different DllImport (because of 32bits / 64bits differences).

To use PropertyHandler sounds like slower, but simpler way.

PatB said:

Saving the ElementID only obviously isn't enough, so i need a sure way to identify the attachment to which this element belongs to.

MicroStation CE exposes PersistentElementPath in native C++ API, which I guess does exactly what you try to implement.

In my opinion, to store unique persistent path from active model to an element in reference, is complex task. It depends a lot on context and exact requirements, because more you know about MicroStation (both tools and API), it's easier to find a way how to break anything straightforward ;-)

I prefer to use not slot, but element id of the reference attachment, because even when a user is able to change a file, defined by the reference (and I guess ID will be still the same), it's rare operation and requires some extra knowledge where it can be done. Of course, such simple solution does not work when references are nested.

PatB said:

since i fear this text is way too long to store in tags

Tags, because of it's so old, limited and fragile concept (with no user friendly API), should not be used in new code. Tags can be changed / removed / corrupted simply by a user.

Even in V8i there are other ways (XAttributes, EC data...) how to store own data in safe way. But, not all are available in C# (like XAttributes), whereas other requires extra knowledge beyond simple Interop API (EC data).

With regards,

  Jan

PersistentElementPath

Jan Šlegr said:

MicroStation CE exposes PersistentElementPath in native C++ API, which I guess does exactly what you try to implement

Good suggestion!

What happens when the element exists in an attachment that is then detached and re-attached?  Presumably the attachment ID is not guaranteed to be the same?  Does PersistentElementPath cope with that problem because it stores a path and not an attachment ID?

Reference Attachment Slot (Pos)

The slot number, as Jan mentions, is a relic from MicroStation V7.  It's an index of the attachment. 

Tags

PatB said:

i fear this text is way too long to store in tags (which Bentley most likely has as a fixed length char-array internally and causes a crash when you give it a longer string, and i don't feel like finding out the length limit

Tag element meta data is provided in the \SDK\include folder...

• Mstn\MdlApi\Tagdata.h
• DgnPlatform\TagElementData.h (DgnTagSetSpec)
• DgnPlatform\DgnPlatform.r.h (DgnTagValue)

You'll find some macros that define values such as max string length.

With CONNECT, ECData and Item Types are a preferred 21^st century choice.