• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 113 subscribers
  • Views 5501 views
  • Users 0 members are here

How to update item types from library

Duncan Gammie
Offline

Is it possible to update item types globally from the dgnlib? 

From what I can see it appears that defining item types in the dgn lib only makes these available to attach. Updating default text in the dgnlib item type does not propagate to the child objects that these item types are attached to. 

My desired workflow is to attach an item type with element description and spec reference to element templates. I would then like to be able to update the text in the library which would then update globally through my project files, updating annotation fields etc. 

It appears the only way I can do this (that I have found anyway) is to edit the default text in the element template, then proceed to update element templates from the library in each file manually. 

Also, can item type libraries be displayed as a table to allow checking/cross referencing and also easier bulk updates? 

  • 0 Offline

    Unknown said:
    Can Item Type libraries be displayed as a table to allow checking/cross referencing and also easier bulk updates? 

    Good suggestion!

     
    Regards, Jon Summers
    LA Solutions

  • 0 Offline

    Have you tried the Update From Library option, this only updates the Item Type name (WAD – Working as per design).

    Try changing the Item Type name for e.g. ElementDescription to ElementDescription1 changing the default value to your requirement. Now use the Update From Library option in the source DGN files. The Item Type name and the value changes. Now go back and change the Item Type name in the DGNLIB from ElementDescription1 to ElementDescription.

    Regards,
    Leonard Jones.

  • 0 Offline in reply to Leonard Jones
    Thanks Leonard,

    Yes, update from library does work when updating item type names, however, to get this to propagate through to my elements is a different matter. To do so I have to update the item type name if it has changed, then update the template library to reflect the default value, then open each file and update templates from library. Hardly efficient, and would push me back to just displaying the required info through a note or standard annotation text. This is at least visible to whoever opens a file.
    In reflection, I don't suppose i even need the item types library, I only need to be able to add a couple text fields to an element template to get what i need.

    I have been excited by the potential of item types, however the more I look in, the more disappointed I am.
    Yes it is quite handy to be able to attach information to an element, however, to do so manually, when so many elements are the same within a file and would require the same updates as a project progresses is quite backwards in my mind.
    What I have been hoping for is a system to allow us to attach specification/notes etc controlled by a central resource, which allows quick update throughout the project. If item types were linked to library then this would quite possibly be it. However, it now seems more like another feature that isn't quite fit for purpose despite WAD and will remain largely unused.
  • 0 Offline in reply to Duncan Gammie

    I agree, Item Types do indeed show a lot of promise.
    Your Item Types could be attached in e.g. a Cell Library. However modifying the values then requires a painful amount of clicks, as opposed to the simple double-click with Tags.

    The Design is incomplete from a User standpoint. Even if it does mostly Work As Designed, the Design is only theoretically usable.

    As with so many things in CONNECT, productivity seems like it wasn't even an afterthought. It's like Design decisions were driven by all sorts of things, except providing increased productivity to the users. The maintenance fees the users are paying are the biggest contributor to Bentley salaries. You'd think Bentley's focus to provide their customers with means to let them do their jobs faster and faster would be unrelenting. Since CE, however, I've been hearing nothing but excuses as to why everything just seems to be slower and takes more time. Doing better than V8i doesn't even seem to be a benchmark at all.

    Customers pay SELECT fees to be more productive with new versions, not to be less productive. Bentley only being focused on driving up revenue, while at the same time only driving productivity up a bit here, but driving it down there, there and there more, simply isn't going to end well.

  • 0 Offline in reply to Koert

    Unknown said:
    Item Types do indeed show a lot of promise.
    The design is incomplete from a user standpoint

    Additionally, MicroStation tags are supported in the APIs.  For example, MicroStation VBA provides various ways to manipulate tag sets and tag elements.  In contrast, there is no VBA API in MicroStation CONNECT for Item Types.  Consequently, if you want to automate something like title block updates, you must remain with tags because it's impossible with Item Types.

    Bentley Systems tell us that MicroStation tags are deprecated in favour of Item Types.  But until you can do everything with Item Types — including programming — that you can do with tags then that is an empty wish.

     
    Regards, Jon Summers
    LA Solutions

Communities
Support and Services
Training and Learning
Social Media