[v8i C#] Copy Fence GetContents attachment patterns missing

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

Parents
  • Hi Stephan,

    do you use CopyContext to copy elements from the attachment? In general CopyContext is responsible to copy not the element only, but also associated elements/data. I am not sure if it works also with patterns, but CopyContext should be used every time the elements are copied from another file.

    Another question: Is your code MicroStation addin or you use Application object to control MicroStation from another process?

    With regards,

    Jan
  • 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.

    Regards

    Stephan

  • 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

  • Hi Jan,

    well, yes, I inherit from Bentley.Microstation.Addin. But for testing purposes I just use VBA now.

    I have tested the code. Unfortunately the pattern does never get copied. It doesn’t matter whether the fence is in clip mode or not.

    For my tests I have the following setup inside one single design file:
    1) Design Model : normal model with patterned shape in it.
    2) Work Model: normal model with “Design Model” attached, here I put the fence around the object and let my script run
    3) Temporary Model: normal model into which the patterned shape should be copied

    What seems strange to me is that the pattern cell “ANSI 33” is already present in the design file, because I patterned the shape inside the “1) Design Model”. So even if I wanted to copy the shared cell definition by myself it wouldn’t make much sense, because it is already in there. Right?

    Regards
    Stephan
  • 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.

  • Hi Stephan,

    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

    With regards,

      Jan

    test-pattern-copy.dgn

    Answer Verified By: Stephan L. 

  • Hi Jan,

    wow, thank you very much! I would have never thought about doing it that way. But reading the code it makes sense. How did you come up with this? It seems that the GetContents function is not working right when retrieving patterned elements from attachment, right? BTW I talked to support and he filed a Defect for that one.

    Well today I was finishing my project with workarounds like sending keyin "fence file", open that file and blabla....but now maybe I will be able to polish things up a little more!

    Regards
    Stephan
  • Hi Stephan,

    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.

    With regards,

      Jan

  • 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

    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?

     
    Regards, Jon Summers
    LA Solutions

  • 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.

    With regards,

      Jan

Reply
  • 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.

    With regards,

      Jan

Children
No Data