Reporting from Item Types in Cells

I have a cell library in which I have defined Item Types and attached them to an element in the cells so that when they are placed, they will have the Item Types already attached. My aim is to produce a report that contains all the Item Type values along with the X,Y,Z coordinates of the cell origin. My report runs on 'Cells + related items.' which are Item Types. I have added all the columns for cell coordinates & Item Types. When I run the report though my table only populates results related to cell property values & not Item Types. The Item Type values do not come through. In the course of testing I have found that my report will work if I place a cell without an Item Type already attached, and then attach the Item Type after it has been placed. This seem like an unnecessary step, & will not work for me anyway as I am also displaying the Item Types in text field built into the cells. So I can’t add them later. I suspect that I can get it to work if ‘Add related Item’ the correct way. However, when I look at doing this I find myself in an endless loop going through an Item Type into a cel into an Item Type into a cell and so on. The screen capture below hopefully demonstrates this. Hoping for some feedback on how to get this to work.

Parents
  • Hi Jovan,

    I know I am jmping into old discussion, but I was not in office for a few days ;-)

    My aim is to produce a report that contains all the Item Type values along with the X,Y,Z coordinates of the cell origin.

    Something similar to this report?

    When I run the report though my table only populates results related to cell property values & not Item Types.

    It is expected result, because the reported object are cells, whereas you attached Items somewhere inside cells, so they are hidden for the report engine.

    I suspect that I can get it to work if ‘Add related Item’ the correct way.

    I think not, because when you attach Item to an element, there is no simple (direct) relation between cell (represented by cell header) and Item, attached to an element inside cell.

    But I want all this to work with an Item Type already attached within a cell.

    You cannot solve your request with Item, attached to "some element" inside cell. In fact, you can, as demonstrated by Jon, using Expressions, but it has some consequences and limitations.

    & will not work for me anyway as I am also displaying the Item Types in text field built into the cells.

    This assumption is incorrect: To use Items in Text element does not require the data must exist (be attached) inside cell.

    Hoping for some feedback on how to get this to work.

    When you want to report cell properties and Item(s) properties, they must be "on the same level", because there is no way, how to specify relationship "from cell to specific element, with particular Item attached". To be precise, in EC representation such relation exists for sure, it is: cell header > one-to-many relationship to child elements > Item is attached particular child element. But it cannot be queried without code, analyzing to what element the specific Item data is attached.

    The solution is to attach Item not to element inside cell, but to the cell itself. It is similar to what you tried manually: To attach Item to cell header. In terms of a cell in cell library, it requires to attach Item to cell (model), not to an element. When such cell, with Item(s) attached to model, is placed, the definition is converted automatically from "attached to model" to "attached to cell header". It's mentioned also in MicroStation help too. When there is any text, using Item as Field, inside such cell, it works fine too: Filed definition is taken from model, and maintained properly after the cell definition is placed to DGN model.

    At the end, because Item data exist "at cell level", they can be included in report simply.

    With regards,

       Jan

  • That's the easy bit. Touched on earlier in the thread.

    Yes, I thought to add my two cents from my perspective. Jovan said it right: This just wasn't intuitive for me. The logging of Idea-I-409 suggests to me that it probably isn't for a lot of other people as well.

    I confess guilty that I am not digging into the documentation for something like this. It should be implemented differently.

    attach Items to the nested elements

    Is the term "nested" right here? Elements may be contained in a cell. Yet a nesting for me is when it comes to cells in cells.

    never be able to predict what Item properties / fields will be required

    Right, for me that may be a task for replacing cell. With tags that was possible (if I recall correctly) Better would be if you could "update" the Item  when some properties have been added in the item definition (that sounds not so hard, does it? Rather should be something that would be a basic requirement. Why do we as users have to.

    The development of items (aka. objects soon as Magesh wrote) should have been to
    1. deliver enhancements to tags (meaning that wherever possible it should be as easy)
    2. enhance the end user handling. (meaning: make it easy to fill out the properties)
    Discussions since the upcoming of items often try to convey the message. 


    The development of physical products often "reingeneers" good ideas from competiors. Not even the handling of the functionality-to-be-replaced (tags) has been implemented. Nor seems anybody have thought about items handling in real world (hundreds of cells with properties). It rather appears that sb. deliberately made it worse. (Copying cells loosing anchoring of labels, no incrementing of numbered properies,...)

    And yes, I am repeating myself and others. The issue in the meantime gives me the impression of screaming in a padded cell. I guess I will stop try riding this dead horse.

    Thank you, back to work

    Need help for the selected function? Click into the "Toolsettings" dialog and press F1    For Screenshots try Win+Shift+S on your Keyboard - Using  "ScreenRecorder" for Videos                          Brauchst Du Hilfe zur gewählen Funktion? Klicke in das "Funktionseinstellungsfenster" und drücke F1 

  • Hi Gerd,

    Sounds like we are both not very happy about the current functionality. You seem to have more concerns about usability, which I do not want to devalue.

    Yet a nesting for me is when it comes to cells in cells.

    By nesting I mean any element that is contained in another... typically this is an element grouped in a Cell, and where a Cell is part of another Cell. A Cell could also have nested elements and Cells. Mstn should allow Items to attach to any one of them. Especially since it is so difficult to tunnel into the nested elements/Cells without dropping and losing info.

    Right, for me that may be a task for replacing cell. With tags that was possible (if I recall correctly)

    Sure, but this is only one use case. At the moment, Mstn can not replace any Cells nested in another Cell. I don't think that this is a sustainable situation. BIM models like MCAD models will be based on assemblies of components. Having everything in a 'flat' hierarchy is unrealistic.

    Better would be if you could "update" the Item  when some properties have been added in the item definition

    Sure, updating the values in the Properties I think you can already do if the Items were attached to the nested elements/Cells. The problem is when the Item needs to be updated with other properties or when you need to add additonal Items to the nested elements/Cells.

    Not even the handling of the functionality-to-be-replaced (tags) has been implemented.

    What tag functionality is still missing? It would be good to have a list in Ideas? Ideally, Bentley would provide a roadmap for delivery but I suspect they have a lot of underlying tasks priorities. Items are much more powerful and pervasive compared to tags.

  • BIM models like MCAD models

    Hierarchical objects are on the wishlist since decades (also Level Hierarchies) I have written that off.

    What tag functionality is still missing?

    I have posted this several times. Also as ideas. While I see the potential they are not implemented in a way that the end user can easily work with them (if you know tags) Tags always had shortcomings. 

    But items are available since what 8 years (?) And were announced to replace tags. Still ppl. ask to keep them. 

    I have not been able to follow ProjectWise Integration.(Has titleblock syncronization been implemented to work with items?)

    but I suspect they have a lot of underlying tasks priorities

    I will not go down this rabbit hole.

    Need help for the selected function? Click into the "Toolsettings" dialog and press F1    For Screenshots try Win+Shift+S on your Keyboard - Using  "ScreenRecorder" for Videos                          Brauchst Du Hilfe zur gewählen Funktion? Klicke in das "Funktionseinstellungsfenster" und drücke F1 

  • Hierarchical objects are on the wishlist since decades (also Level Hierarchies) I have written that off.

    Not sure what you mean here. I am just looking for the basic Cell functionality in Mstn to be honoured when working with Items. Mstn has been quite good at 'heirarchial objects' at file model level if you look at its Ref file functionality. I think that all BIM processes will require federating 'hierarchial objects'. These days this also means dealing with 'hierarchial objects' authored by other apps.

    The industry has been moving away from loose elements to smart objects for decades. These objects need to be aggregated up in assemblies. Even the basic Parametric Cell will be made from component objects constrained together MCAD style. Monolithic objects are problematic like their software equivalents. Loose unstructured elements will be stuck in the low productivity everything needs to be manually edited past.

    I can understand why you may have written this off. After all, after eight years... better to lobby for the basics or recover the old level of functionality first, right? I share your frustration. The slide below is from 2006.

  • Hi Rob,

    Not sure if you saw this thread. It looks like there is a way to extract measurements from the parametric solid geometry within the Cell.

    It would be good if someone could suss the SmartFeatureSchema.ecschema.xml file and understand how to generate the expressions for other features.

    Worthy of another thread as you say.

    I suppose the hack would be to place an associative dimension to the feature or subfeature you want to measure and extract the info from the dimension element. Would the 3D Distance Constraint be better? Probably a bit bloaty but also more flexible and less dependent on what is exposed via the available schemas, Symbol providers etc.

Reply
  • Hi Rob,

    Not sure if you saw this thread. It looks like there is a way to extract measurements from the parametric solid geometry within the Cell.

    It would be good if someone could suss the SmartFeatureSchema.ecschema.xml file and understand how to generate the expressions for other features.

    Worthy of another thread as you say.

    I suppose the hack would be to place an associative dimension to the feature or subfeature you want to measure and extract the info from the dimension element. Would the 3D Distance Constraint be better? Probably a bit bloaty but also more flexible and less dependent on what is exposed via the available schemas, Symbol providers etc.

Children
No Data