Issues can arise that impact the updating and modification of hatch objects. This article focuses on the following situations that might occur after making changes to objects in your drawings associated with hatch objects:
By default, hatch objects are associative, which means they are associated with the objects that define their boundaries. Associative hatch automatically adjusts when their boundary objects are modified. However, as objects are modified in a drawing, hatch objects can become disassociated if the boundary geometry is deleted or exploded.
Once a hatch object is no longer associative, you can do one of the following to reshape or adjust the hatch's boundary:
When a hatch object is on a locked or frozen layer while its associated boundary is modified, the hatch object isn't updated. This causes the hatch object to no longer fill the newly defined boundary.
If you catch this issue right after editing the boundary of a hatch object, you can undo the edits and then unlock or thaw the layer before redoing the edits to the boundary objects. However, if you didn’t catch the issue right away, you can do the following to update the hatch object:
The boundary is not stretched but the hatch updates to the fill the current boundary.
If you have experience with AutoLISP, the following source code example demonstrates how to update all hatch objects on the current layout. The AutoLISP source code can copied/pasted to the Command prompt or used as part of another AutoLISP program. Before running the AutoLISP source code, unlock or thaw the layers on which the hatch and boundary objects are placed.
(vlax-For obj (vla-Get-Block (vla-Get-ActiveLayout (vla-Get-ActiveDocument (vlax-Get-Acad-Object)))) (if (= (vla-Get-ObjectName obj) "AcDbHatch") (if (= (vla-Get-AssociativeHatch obj) :vlax-true) (vla-Update (vlax-Ename->vla-Object (cdr (assoc 330 (reverse (entget (vlax-vla-Object->Ename obj))))))))))