Why do dynamic block with stretch behave differently in drawings

[Anonymous]

I have created a library of dynamic blocks to distribute.  But my testing finds too many errors when blocks are stretched. For instance in the following block (274100-004-ID MASKING SCRN.dwg), I completed the editing and tested the block in the BE command. Here is the picture of the stretched blocks (note, the origininal stretch point aligns with the T2 on Std view):

I inserted this block in my test drawing, stretching both the Std view and the Boxed view (with the brown background).  But the results were dramatically wrong in both views:

In the past, I have done this same thing pattern for editing:

1. Create or Edit as discrete block
2. Place block in test or library block
3. Test stretching
4. If errors, edit within test or library block
5. Wblock back to discrete block

The difficulty is that I do not know when I will get an error the next time it is used in any drawing.

How can I guarantee stability of these stretches?

[ojuris]

hi!

try attached file

I made new associated hatches for first two visibility states

[Anonymous]

Thank you so much for the prompt reply.  The block does work! 

This brings me to a major problem of how to deal with Associative Hatch.  At one time, I did all my hatches within dynamic blocks with it, but continually had difficulties, such as:

1. With subsequent editing of the blocks, the Associative property disappeared
2. If you click on Associative within Quick Properties, it would change it back, but this method seems more unstable
3. I had to resort to deleting/adding hatches on a continuous basis
4. On 06-19-2016, BB1352 responded that it didn't matter what hatch I used

So, my questions are:

1. When is Associative Hatch required in Dynamic Blocks? Stretch? Scale? Other instances?
2. How can I edit to Associative when this attribute is either not correctly created or changes back to off?
3. Where is this documented anyplace?

BTW: In the sample you returned, I noticed one of the (what I consider) bugs in Dynamic Blocks--Move Point command is unstable.  I placed the block on my test dwg then stretched in Std View.  Stretch holds in Boxed view (as planned). Then I used Move Point in center of Circled view.  But one of the other hatches on the right side did not move, as shown below:

It seems that you must always go to the Visual Style where (each) Move Point was used, then turn BVMODE on, use New Select Set.  Now the Move Point will be stable in all views.

Thank you again for your quick response.

[ojuris]

hi!

about block - I didn't recreate that hatch because it doesn't move in standard visibility state, now I recreate it - see attachment

about hatch - I don't use it very often in DB but mostly I use associative hatch and try to attach to actions only geometry not hatch

[Anonymous]

Thank you.  The bug I noted above is still there. If you go to Circled view and move from center point (move point), then go back to Std view, the right hatch does not move.  This always happens unless you create a new selection set with BVMODE = 1. 

[ojuris]

hi!

I don't have that bug

I just download file from my last message, insert block in drawing, stretch, go to Circled view and move (I see there 2 possibilities to move), then go back to Std view and all hatches are in correct place

[Anonymous]

I am getting VERY frustrated with AutoCAD Dynamic Stretch on Hatch patterns.  I went thru every block I have that uses stretch and redid the hatch patterns, tested them and placed them in a library drawing.  Each stretch block works find on the library drawing and in Test within BE.

Now I am testing my CUIX and most of them (but not all) blew up.  Here is an example using the attached 274100-005-OB PROJ SCRN.dwg

1. Test of original discreet block

There were no stretch errors

2. Tried same thing on the Library file with good results:

3. Using my CUIX, I placed this block in a new test dwg and most of my 20 items with stretch do not work correctly. 

4. I also tested it with BrisCAD V17. It also had NO errors in stretch using the same library file.

Lest you think this was because of the CUIX, here is the insertion string:

^c^c-INSERT "274100-005-OB PROJ SCRN";\;;;

Here is the entire statement for this command from the CUIX\MunuGroup.cui:

 <MenuMacro UID="MMU_1570">
      <Macro type="Any">
        <Revision MajorVersion="16" MinorVersion="2" UserVersion="1" />
        <ModifiedRev MajorVersion="21" MinorVersion="0" UserVersion="1" />
        <Name xlate="true" UID="XLS_00025050">Projection Screen (SCRN)</Name>
        <Command>^c^c-INSERT;"AV_SYMBOLS_Pro_ISO";^C--INSERT "274100-005-OB PROJ SCRN";\;;;</Command>
        <HelpString xlate="true" UID="XLS_00025051">Projection Screen-Scalable</HelpString>
        <SmallImage Name="FP32-ProjectionScreenAV.bmp" />
        <LargeImage Name="FP32-ProjectionScreenAV.bmp" />
        <CLICommand xlate="true" UID="XLS_210_766C0">Projection Screen (SCRN)</CLICommand>
      </Macro>
    </MenuMacro>

HOW CAN I GET THESE HATCH PATTERNS CONSISTENTLY RECALLING CORRECTLY?????????

[Libbya]

You've got something weird going on.  When I fix the hatch, WBLOCK, and then insert that block into another new drawing the hatches lose associativity.  When I explode your block, make a new block definition, redo the associative hatches, WBLOCK, and then insert the new block it does *not* lose associativity.  I feel like something is corrupted in your block definition and remaking the block may be the best solution.  It stinks if the same is true for your 'library'.

[Anonymous]

You are correct--it stinks.  I have remade these blocks numerous times and get back to the same problem on Stretch with Hatch. I have made countless redo of hatching, using both Annotative and Associative.  I think there is a basic instability with hatch/stretch combo commands in dynamic blocks with some complexity.  At least this is only 10% of my library, but I am supposed to launch the website with these next week.  FUN!!

Perhaps I should leave out the hatch and let them color their own. Only way I can see to get and keep it stable. No instability when there is no hatch.

I had noted above the procedure to get Move Point to fail. I think this is probably a bug also.

Thank you.

[Libbya]

To be clear, with extensive dynamic block experience I have seen very few issues with associative hatches and stretch actions aside from your block.  The system seems quite solid.  What I experienced was specifically an issue with your block file.  Once I recreated, the issue was resolved.  If you are having to recreate blocks multiple times, then you must have some issue local to your computer that is causing the failures.