how to create holes within a "hatch/pattern/flood/etc"

Good day everyone

What would be the most practical way to create a hole, in a hatch?

Advice is appreciated

thank you

Win 10

Microstation v8i - SS4

( I like to be able to see what I am snapping to )

unhighligthed hatch body

highligthed hatch body

Parents
  • Hi Jeffrey,

    as mentioned, it's hard to guess the best approach from small image, without knowing how the model is structured. But as wrote, the flood option, available in hatching and patterning tools, allows to recognize interior shapes.

    But I have small problem with the picture you provided: You are asking about hatching / patterning, but the shape on your picture seems to be filled, not hatched. Or you use "old AutoCAD style" how to fill polygons using hatching?

    With regards,

      Jan

  • Thank you so much everyone for your help and support, and I apologize for the poor example. I try to create a couple examples using SnagIt, but I have to figure out how to size the window to it doesn't appears too large.

    I was able to create what I wanted using and method, and I just have to identify which way is best for what I am trying to do.

    I would like to be able to draw complete shapes, and by using the "Bring to Front" function stack shapes on top of each other, and hiding what may be behind it; thus way I can make changes to a drawing without having to redraw anything if possible. I am able to do it in AutoCAD using a "Draw Order Layer" function, but I believe the version I am using of Bentley is not as flexible as newer versions may be.

    I may have to completely change my approach to achieve what I am trying to do, and I certainly welcome any advice anyone is willing to share.

    Thank you all again for your time, and wish you a great day

    Stay healthy 

  • I have not, but I will start to use it now that I know it functions like AutoCAD.

    Thank you

  • If it helps, I believe that you can assign "priority" byLevel or by element. ByLevel may be a more organized way to do things, but by element can get the job done.

    MaryB

    Power GeoPak 08.11.09.918
    Power InRoads 08.11.09.918
    OpenRoads Designer 2021 R2

        

  • ByLevel may be a more organized way to do things, but by element can get the job done.

    Yes, I agree it can get the job done.

    But my experience is that in longer term, it always leads to chaos and confusion, because when everything is ByLevel (which is moreover closer to standard AutoCAD concept ;-), it's simple to modify anything and also to check the file for conformity. But when attributes are set individually at elements, nothing can be checked.

    Regards,

      Jan

  • and by using the "Bring to Front" function

    Do not use it!

    This function is very old and treated as obsolete, because based on order of elements in design file (which is roughly equal to an order how the elements are drawn). The problem is that the order ca be changed anytime, when an element is modified and has to be moved to the end of the file, which is often out from a user control.

    I'm not sure who considers it obsolete, I certainly do not and I still use the functionality frequently via an old BASIC macro which continues to work as it has for the last 20 years. Whilst Element Priority has its place, I use it for more complex compositions whereas sending an element to the front or back is for me is a perfectly acceptable choice in the right circumstances.

  • I'm not sure who considers it obsolete

    It has been discussed widely when MicroStation V8 XM Edition (14 years ago) was released and element priority feature was introduced.

    When Display Styles were available later, legacy file order display has been still supported, but maintained primarily for backward compatibility, not as preferred technology.

    I certainly do not and I still use the functionality frequently

    When a feature is obsolete / legacy, it does not mean it does not work. It's only the information it's not in a main development focus, probably not very actively tested, but still maintained. Bentley try to maintain obsolete tools for extremely long time, plus in this specific case it's simple.

    via an old BASIC macro which continues to work as it has for the last 20 years.

    MicroStation BASIC macros is a good example of a feature life cycle: BASIC was announced "to be not actively developed anymore" in MicroStation V8 XM Edition with a recommendation to migrate to VBA. But even when outside from development focus, it has been maintained to the end of V8i life cycle (to V8i SS10).

    MicroStation BASIC macros are not available in CONNECT Edition, so from the information "we do not develop it now, will be probably removed in future" to "it was removed" it took nearly 10 years (from V8 XM Edition release to the first CONNECT Edition version).

    is for me is a perfectly acceptable choice in the right circumstances.

    It's not in conflict with what I wrote: When it works, great. But to recommend it to learn it and use it today is not good at all. The file order can be corrupted (changed) very easily even with simple element modification, so from today perspective, it's not generally robust feature.

    Regards,

      Jan

Reply
  • I'm not sure who considers it obsolete

    It has been discussed widely when MicroStation V8 XM Edition (14 years ago) was released and element priority feature was introduced.

    When Display Styles were available later, legacy file order display has been still supported, but maintained primarily for backward compatibility, not as preferred technology.

    I certainly do not and I still use the functionality frequently

    When a feature is obsolete / legacy, it does not mean it does not work. It's only the information it's not in a main development focus, probably not very actively tested, but still maintained. Bentley try to maintain obsolete tools for extremely long time, plus in this specific case it's simple.

    via an old BASIC macro which continues to work as it has for the last 20 years.

    MicroStation BASIC macros is a good example of a feature life cycle: BASIC was announced "to be not actively developed anymore" in MicroStation V8 XM Edition with a recommendation to migrate to VBA. But even when outside from development focus, it has been maintained to the end of V8i life cycle (to V8i SS10).

    MicroStation BASIC macros are not available in CONNECT Edition, so from the information "we do not develop it now, will be probably removed in future" to "it was removed" it took nearly 10 years (from V8 XM Edition release to the first CONNECT Edition version).

    is for me is a perfectly acceptable choice in the right circumstances.

    It's not in conflict with what I wrote: When it works, great. But to recommend it to learn it and use it today is not good at all. The file order can be corrupted (changed) very easily even with simple element modification, so from today perspective, it's not generally robust feature.

    Regards,

      Jan

Children
No Data