Hey,
I define a fence, get an enumerator with Fence.GetContents() and use CopyElement(...) to copy all containing elements to a temporary model.
This works fine and as expected UNLESS I try to copy elements that are in an attachment: If I put a fence around an attachment and try to copy the elements then the patterns are not copied. Hatching works fine, but patterns (shared cells) are missing.
Is there something that I have to take care of when dealing with patterns?
Regards
Stephan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Hi Jan,
thank you very much for your reply.
I use CopyContext and checked the docs about it. I could not find anything about patterns. Only about levels, graphic groups and whether the copied elements should be created in file or memory-only. Short answer: I use CopyContext with default values.
My code is an addin. I use C# with references to the "old" COM/VBA dlls. Patterns from ActiveModelReference work fine, only patterns from attachments don't get copied.
Oh, I thought that a C# addin would be the same as VBA in terms of processes. No? I just code in C# and start my addin via keyin - inside Microstation.I will check if my example works with VBA and will let you know.
Well, it might be that the patterned element gets clipped. I'm not sure right now. But it could happen in future, so that is something I have to take care of.
Yes, I also thought that maybe the shared cell doesn't get copied or something like that.
Well, I will try out VBA and post my experiences here...
Hi Stephan,
Unknown said:I thought that a C# addin would be the same as VBA in terms of processes. No?
I don't know the details, but I guess if your application is addin (a class inherited from Bentley.MicroStation.AddIn), it's similar to VBA. But if you use Application object from external exe, the code is run in another process than MicroStation.
Unknown said:Well, it might be that the patterned element gets clipped.
This should be tested. Maybe the code works fine when the element is not modified, but fails if the element is clipped?
With regards,
Jan
Unknown said:Even if I wanted to copy the shared cell definition by myself it wouldn’t make much sense, because it is already in there
I believe that a shared cell definition element is a DGN file component rather than belonging to a particular model. It's probably stored in a non-visible model, but that's just a guess.
Draw an analogy with a normal cell: a cell is a DGN model having the attribute 'can be placed as a cell'.
Regards, Jon Summers LA Solutions
Yes, I believe that, too. So, I guess that the "should be patterned" shape in the temporary model could find the ANSI33 pattern. Somehow it doesn't want too. Hm... maybe while being copied it forgets about the linkage to that shared cell definition.
I think I will clean up my test case a little more, so that there is no shared cell definition in the file, in which my script runs, but only the attachment.
I thought about your issue a bit more ... frankly, a kind of short escape from end-of-the-year duties and madness ;-)
This code works (at least with my simple test design file), the trick is in how the copied element is retrieved.
Public Sub TestCopyElementsUsingFence() ' Code doesn't work if no fence is defined If (ActiveDesignFile.Fence.IsDefined = False) Then MsgBox "Fence is not defined." Exit Sub End If ' Target model is where the element will be copied to Dim targetModel As ModelReference Set targetModel = ActiveDesignFile.Models("Target model") ' Get fence enumerator and to process it Dim ee As ElementEnumerator Set ee = ActiveDesignFile.Fence.GetContents(False, True) Do While ee.MoveNext ' From what model the element comes from? Dim reference As Attachment Set reference = ee.Current.ModelReference.AsAttachment Dim elemId As DLong elemId = ee.Current.ID ' Get the element using its model reference and id Dim el As Element Set el = reference.GetElementByID(elemId) ' Add the element to target model targetModel.AddElement el Loop End Sub
test-pattern-copy.dgn
Answer Verified By: Stephan L.
Unknown said:How did you come up with this?
Frankly, it just arised in my mind. Maybe I should ask Sigmund Freud about my subconsciousness :-) Part of this idea comes from my older project, where I used element ids to identify and manipulate elements and everything worked fine. So I tried how it works for elements with patterns and fortunately it seems to be the solution.
Unknown said:It seems that the GetContents function is not working right when retrieving patterned elements from attachment, right?
Yes, I agree it's the bug. I see no reason why enumerator received from GetContents should not work.
Unknown said: Dim elemId As DLong elemId = ee.Current.ID ' Get the element using its model reference and id Dim el As Element Set el = reference.GetElementByID(elemId) ' Add the element to target model targetModel.AddElement el
Dim elemId As DLong elemId = ee.Current.ID ' Get the element using its model reference and id Dim el As Element Set el = reference.GetElementByID(elemId) ' Add the element to target model targetModel.AddElement el
I'm pleased that you solved the problem. But I'm also puzzled as to why that works. Once would imagine that using a CopyContext should do the job. But why does simply adding an element do the job better? Is it significant that you used GetElementByID rather than the direct contents of the fence enumerator?
I haven't tried this with MDL, so can't compare with VBA. Do you know if a similar problem exists wth MDL?
Hi Jon,
Unknown said:But I'm also puzzled as to why that works.
Me also ;-) As we don't know how VBA API is implemented, we can only guess how element enumerator is created. I suppose some "lightweight reference" to an elemetn is stored and the context is lost. And the question is if it's WAD or a bug.
Unknown said:But why does simply adding an element do the job better?
My experience (which is quite limited) is that in VBA and NET addins CopyContext is rarely required and the simple adding is enough. As far as I remember I have used CopyContext when worked with tags from references (as tags are weakly coupled with elements), but it's probably all.
Unknown said:Is it significant that you used GetElementByID rather than the direct contents of the fence enumerator?
It was just an idea to try it, based on my former code I worked with elements from different attachments, so I identified them using modelRef and elemId pairs.And it seems it identifies elements better including relations and context than element received from enumerator.
Unknown said:Do you know if a similar problem exists wth MDL?
I have no idea.