Hatch boundary associativity removed

[michael.12445]

Does anyone have an explanation why, when editing a polyline boundary that has been hatched, sometimes the hatch associativity is preserved, and sometimes not? Sometimes moving or inserting polyline vertices results in the hatch following the changed boundary shape and preserving its associativity, and sometimes moving or inserting a vertex changes the polyline shape but not the hatch, and AutoCAD spits out the message "hatch boundary associativity removed." Why?

I'm seeing this behavior in 2008, although it also occurred in earlier versions. It doesn't matter whether the polyline is edited using grips or the PEDIT command, nor does it matter whether the entire boundary is visible on the screen or not.

Any ideas?

[irneb]

I've never found this before. What I've seen is after PEdit the hatch doesn't update until you gripedit it. But that's because I'm using "Heavy Weight" Polylines (i.e. PLINETYPE=2). With the default PLINETYPE=0 you should have LWPolyLines which do not have this issue. But even with the older polylines I've never found a PEdit / GripEdit to break associativity, only in some cases with the Trim command did this happen.

[lpseifert]

Check the Pickstyle system variable.

[michael.12445]

In the drawing with the issue, PICKSTYLE = 1. But before I read the reply about PICKSTYLE, I edited the polyline to its new shape, then erased the (non-associative) hatch and re-hatched the polyline, making sure the "associative" box was checked in the BHATCH dialog. Then I tried moving around a couple of the vertices, and the hatch appears to keep its associativity (though I didn't try every vertex). But the properties palette definitely reported that the original hatch was associative, before I moved any vertices of its bounding polyline.

Because of different people working on this drawing, it may have been saved in 2004 dwg format from 2008. Could that be the issue?

[lpseifert]

It appears that Pickstyle needs to be 2 or 3

from Help

PICKSTYLE

Controls the use of group selection and associative hatch selection.

0 No group selection or associative hatch selection

1 Group selection

2 Associative hatch selection

3 Group selection and associative hatch selection

[irneb]

It appears that Pickstyle needs to be 2 or 3

from Help

I'm not sure that's the case. I've got mine set to 0 as I usually don't want to select 2 or more entities at once when I pick only one. And I have not found this problem.

BTW Micheal, was the original hatch made using pick-points? Or select objects? If the former, that may be the issue as pick-points actually selects everything visible on the screen, not just the entity(ies) forming the boundary(ies). Thus modifying anything else may also cause hatch problems, not to mention that stupid question about "You've selected ###### entities ... Are you sure you want to do this?"

And then just a shot in the dark . What's the state of the layer on which the hatch resides? Locked / Frozen / Off? It "shouldn't" cause problems with associative hatches, but you never know.

[irneb]

Because of different people working on this drawing, it may have been saved in 2004 dwg format from 2008. Could that be the issue?

It "shouldn't" be the reason. Associative hatching was introduced way before 2004, so that shouldn't be different between 2004 & 8. I can't even see that saving back to R14 DWG should cause this issue as associative hatches was available in that as well.

[michael.12445]

I'm not sure that's the case. I've got mine set to 0 as I usually don't want to select 2 or more entities at once when I pick only one. And I have not found this problem.

BTW Micheal, was the original hatch made using pick-points? Or select objects? If the former, that may be the issue as pick-points actually selects everything visible on the screen, not just the entity(ies) forming the boundary(ies). Thus modifying anything else may also cause hatch problems, not to mention that stupid question about "You've selected ###### entities ... Are you sure you want to do this?"

And then just a shot in the dark . What's the state of the layer on which the hatch resides? Locked / Frozen / Off? It "shouldn't" cause problems with associative hatches, but you never know.

AFAIK the original hatch was made by first drawing a closed polyline, and then selecting it as the boundary in the BHATCH dialog. I never got the "Are you sure you want to do this?" prompt. The layer on which the hatch resides is on, thawed, and unlocked. I've seen hatches not update with their boundaries if the hatch is on a locked layer, but that's not the case here - it updated when some vertices of the boundary were moved, but not others.

[irneb]

OK, this is real head scratching. One last possibility: is the polyline closed? I don't mean is its end point on top of its start point, rather does its Closed property in the property palette indicate "Yes"?

I know it sounds "stupid", but I have seen people "close" a polyline by simply stopping it where it began. Pediting such could break the associativity. Also if 2 points are exactly on top of each other - rather use the straighten opening of PEdit-Edit Vertex to remove points than grip-editing them onto an existing point.

[BlackBox]

...
I have seen people "close" a polyline by simply stopping it where it began. Pediting such could break the associativity. Also if 2 points are exactly on top of each other - rather use the straighten opening of PEdit-Edit Vertex to remove points than grip-editing them onto an existing point.

This type of "closed" polyline gives me trouble when preparing an XCLIP... I resolve the issue by using the ._Boundary command. I know this does not answer the "why?" posed in this thread, but it may provide for a limited workaround.