Hi,
I have got a shared cell which contains extended elements(type 106). In my mdl code, I am getting the transformation matrix of the shared cell and applying it on all the extended elements in the shared cell. But the they got transformed incorrectly. Is there any thing I missed ?
Regards,
Rup
Unknown said: I am applying [the transformation] to all the extended elements in the shared cell
What do you want to achieve?
Regards, Jon Summers LA Solutions
I want to display the shared cell containing extended elements correctly in my software.
Actually when I use the mdl function to read the shared cell, I am setting the flag "transformToWorld " to "TRUE". But this is not getting applied to AutoPLANT extended elements(extended elements that comes from autoplant). But this is getting applied to ordinary extended elements.
mdlSharedCell_read
(
&pNewElemDescr ,
pMSElement ,
TRUE ,//BoolInt transformToWorld ,
m_pDgnModelRef ,
FALSE //BoolInt expandNested
);
So I want to know how to distinguish the AutoPLANT extended elements.
Unknown said: I want to know how to distinguish the AutoPLANT extended elements
You're still looking for a way to recognise an AutoPLANT object?
Post a small DGN model here that contains an AutoPLANT shared cell. Let's see if there is something about that object that reveals its progenitor.
Jon,
Please find the file attached. The green colored cell is getting transformed correctly with the following function but not the yellow colored cells.
mdlSharedCell_read ( &pNewElemDescr , pMSElement , TRUE ,//BoolInt transformToWorld , m_pDgnModelRef , FALSE //BoolInt expandNested );
If you use the old Analyze Element tool (keyin: analyze element) you can see a Dependency Linkage on the shared cell. That linkage mentions AutoPLANT (see attached screenshot). The newer element information tool doesn't reveal that dependency.
If you can figure out how to use the Dependency API (mdlDependency_api) then you can extract the linkage from the shared cell and deduce its AutoPLANT origin.
I don't know why the type 106 extended element is not transforming correctly. Perhaps it requires an element handler that is not available to us.
Thank you so much for valuable information.
Can 10006 be the AppId of the AutoPLANT as per the above bmp ?
Unknown said:Can 10006 be the AppId of the AutoPLANT as per the above bmp ?
No: 10006 is DEPENDENCYAPPID_SharedCellDef (#include <dependency_appid.h>).
Clearly the dependency linkage stores the AutoPLANT information, but I can't tell you where or how (the Dependency API is somewhat opaque).
user="Jon Summers"]I don't know why the type 106 extended element is not transforming correctly. Perhaps it requires an element handler that is not available to us.
The handler for this extended element is part of MicroStation, so it's not an issue with a missing handler. This is a good thing to consider though, it illustrates why modifying elements just to extract geometry is a bad idea; they aren't obligated to support a given operation. However, in this case you can use the Drop Element tool to drop shared cells to geometry to get just the 106 by itself, no problem with dragging the 106 around, so it does transform correctly (SS3).
What are you are doing to post-process the edP you get back from mdlSharedCell_read? I'm going to assume that you are using the IElementGraphicsProcessor to extract the geometry from the 106, are you accounting for any non-identity transform that may have been supplied to your AnnounceTransform method?
-B
Yes Brien, I am using IElementGraphicsProcessor for processing extended elements. And I am also honoring the transformation matrix that is provided by AnnounceTransform method.