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.
Hi Jovan,
I know I am jmping into old discussion, but I was not in office for a few days ;-)
Jovan Djukanovic said: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?
Jovan Djukanovic said: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.
Jovan Djukanovic said: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.
Jovan Djukanovic said: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.
Jovan Djukanovic said:& 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.
Jovan Djukanovic said: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
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Thanks Jan, I realised that I can only achieve what I want with Item Types & Reports by attaching Item Types after the cells have been placed. Being green on Item Types it just wasn't something occurred to me as some sort of limitation. The workflow I would want to achieve would be helped immensely with something like New Idea – MS-I-409.
Hi Gerd,
That's the easy bit. Touched on earlier in the thread.
What would be much more useful is if you can attach Items to the nested elements after they are placed (as part of a parent Cell).
You will never be able to predict what Item properties / fields will be required. There will always be more.
dominic SEAH said: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.
dominic SEAH said: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.
dominic SEAH said: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 to1. 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
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.
mlm said: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.
mlm said: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.
mlm said: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.
mlm said: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.
dominic SEAH said:BIM models like MCAD models
Hierarchical objects are on the wishlist since decades (also Level Hierarchies) I have written that off.
dominic SEAH said: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?)
dominic SEAH said:but I suspect they have a lot of underlying tasks priorities
I will not go down this rabbit hole.
mlm said: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.