Ability to override hatch attributes in Viewports

[Christiaan]

Currently (v12.5.1) if you apply a colour to any of your hatches you can't then override them in a Viewport because they're not associated with a Class.

I can't think of the best way around this. The first thought would be to add the ability to put Hatch Levels on a Class, but maybe that's not a good idea? Maybe, instead, there needs to be a special hatch override feature in Viewports?

[Dieter @ DWorks]

that's a very good idea! it would be very easy to use it that way. then we don't need to work around this.

You can make a duplicate of the hatch, edit it to the wanted color, and set the attributes of the class the object is in to that hatch, that's the way i do it.

[islandmon]

Christiaan, as usual, is pointing out an important 'get at & change ' problem with hatch components.

Now that the power of Viewports has changed the way we create & compile, the need for better access via VP to all CAD components looms ever larger.

Is adding access to classes the solutions so that every element & object has a class with the added ability to override them via VP?

Will this then make Viewports a SuperLayer ?

Or as someonenamedlink suggests the ability to duplicate & edit similar to LayerSpace should be allowed in Viewports.

Are Viewports designed to be the Master Editor Layer? Or should a VP be limited to the role of compositor and controller of information

with limited editorial annotations.

[P Retondo]

Islandmon, your question is a significant one. At what point does viewport customization become a bureaucratic nightmare? We already have major control over what a viewport can do - perhaps what Christiaan would like should be done by more "traditional" VW methods? Is that a fair inference from your question?

Christiaan and link, maybe you could offer us an example of a situation where you would want a hatch to appear in a viewport differently from the way it appears in a design layer.

[Christiaan]

Pete, the situation arises when you want to keep one object coloured but make everything else black.

Since Viewports came along we adopted a system whereby we draw on Design Layers in colour (according to Class) and then when we present our drawings on a Sheet Layer we do one of three things:

1) leave as is, in colour

2) choose 'Black and white only' from document preferences, or

3) if we need some colour to remain, override all Class settings in the Viewport to black, apart from the object we want to remain in colour.

One real world example of option 3 is lease/conveyancing plans (or site plans) where, at least in the UK, the boundary line is required to be red. In a recent job I was producing lease plans and we had a coloured hatch indicating a floor finish. In this instance I had to go back to the hatch and edit it to be black, which we would rather have remained coloured on our Design Layers (for the very reason that we started using colour in the first place).

In the case above it wasn't such a problem because it didn't really matter that the hatch was now black (because it was just a visual aid), but I can see a different workaround is going to be needed on another job where we require the hatch to remain coloured (because it indicates some landscaping on a different drawing). In this case we're going to have to redraw the boundary in the Viewport Annotation and control the colour of it via the Attributes palette.