custom hatch pattern

one for the guru's..

Can a hatch pattern be made that uses wipeouts?

 

express tools has a super hatch that can hatch with a wipeout

 

that however does not create the hatch pattern. (it's the actual pattern
i want).

 

you create the hatch as a regular block or image etc
refer to express tools help for futher info

 

i've been able to create a hatch that way.. just not a hatch pattern.
it can't be re-used or modd'ed.

my goal here is to have it listed in the hatch dialog, not to have to
re-create it every time i want to use it.

 

To the best of my knowledge, that's not possible. To be a regular hatch pattern, it's got to be made up of vectors conforming to the syntax of a pat file:

angle, x-origin,y-origin, delta-x,delta-y,dash-1,dash-2, ...

There's no provision in there for anything other than these "line" elements.

 

Do you want the entire pattern to behave as a wipeout, or just parts of it?

If the whole thing is to be a wipeout, you can use a solid hatch colored
with a pen set to 0% in the ctb file.

Only works if the linemerge setting within the pc3 file is set to "lines
overwrite".

 

ok.. a little more in-depth..

take the standard ansi31 hatch as a demo..

I'd want to combine that pattern with a wipeout. The result would be a
hatch that could be overlaid on another pattern, obscuring it without
having to edit it. (it's hard to make you see how this would be of use
without you knowing the inner workings of what we do).

 

you couldn't use a hatch with the color changed to a 0% (plots white) pen ?

 

Okay, try this, place a wipeout around the are you want to obscure (pline,
or boundary command for flood), then hatch the wipeout, make sure the hatch
is associative, and set to place in front of the wipeout boundary. this
will let you move or stretch the wipeout and the hatch will alter
automatically. Unfortunitly, it would not be a single object, or be place
all at once, but you could then get some lisp to tie the commands together
into a single command, and maybe a reactor to bind the objects together (if
one goes, they both go, type of thing) with some fancy vb.

 

you are not understanding...

hatch a
hatch b (looks like ansi31 but has a wipeout behind it)

hatch A exists in a drawing, I create hatch B and move it ontop of hatch
A. You can no longger see hatch A below Hatch B, but can still see hatch B.

Follow?

this new hatch isn't ment to just block out other objects, it's ment to
funtion/look like a regular hatch with the added bonus of being able to
hide the objects behind it.

 

that isn't an option. the only time we allow wipeouts in our drawings
is when they are a part of a block (zero chance of being left behind
after a move, erase, etc.. and we did try reactors, they don't do the job).

we also have a handy lisp that removes ALL wipeouts that are not safley
inside a block (as they should be).

 

Now that you've described further, I think Tim's onto a valid approach that could probably be automated, but it's not going to be through your hatch dialog, because what you're wanting simply isn't within the realm of possibility for pat files as they're presently defined.

I can understand your wipeout rule -- it's a reasonable safeguard against "what if" problem scenarios. But it's also worth considering that when a rule gets in your way or prevents making an improvement, it may be a sign that the rule needs to be reconsidered.

I chair our firm's "standards committee" and this is something we often reflect upon. The rule, after all, is our own creation. We can change it, abolish it, strengthen it, revise it, give it exceptions, or sharpen its focus, if we choose. Some rules are firmer than others. Sometimes, in response to a perceived need, we compose a working or provisional rule, and attempt to apply it for a while, just to see how it bears out in practice. Usually, after trial period, we're able to restate the rule in a simpler and more pertinent way. But we never would have gotten there if we insisted that every rule be perfect and absolute from the get-go. None of the rules, ultimately, are absolute values in and of themselves. They're only a means to a larger end. Sometimes you can find a way to accomplish the goal in a new way, and the whole reason for the old rule just evaporates.

So okay, what about a routine that made the wipeout and hatch as per Tim, then combined them into an anonymous block? That's not hard. Or what about making them a group? Either of those would get around your orphan-wipeout rule.

 

Hi, I've just tried a version of what was being suggested - and it works for
me.

How about associative hatching, on whatever layer suits, the wipeout and
making an anonymous group of the two. Stretch or whatever as required (if
necessary at all), then when all is exactly as you want it, make them into a
block. If you then follow that with the "Tframes" command, the border
polyline will disappear and just the hatch remains, obliterating whatever is
behind (beware of draworder though). It will regen and plot correctly (as
per the display).

I'm sure it would not be too difficult to automate the wipeout, hatch,
group, block and Tframes stages, making the whole process reasonably
effortless and compliant with your "no wipeouts outside of blocks" rule.

Regards,
Gordon.

 

it's very true that every rule has it's time.. and on occasion that time
runs out.

the problem being how to "adapt".

"isn't within the realm of possibility for pat files"
- that cuts off hope for this "idea"

your suggestions while they would work in a limited capacity, they would
fall flat in the wide world of cad.
it's all about finding the solution, without giving up the ability to
edit "on the fly".

But thanks for trying (really).
C Witt

 

ok, how did you do that?..

I can't edit the "wiped out" area.. not to mention that i can't figure
out how it was done..

It's not attached to either hatch object, as they can be erased with no
effect. it's not another layer.. only one in the drawing.. not a
wipeout (at least not one with a frame so it can be seen).. cliped?..

 

a black solid hatch.. hmm.. nice idea.. but then we can't plot the
drawings (big black blobs take away from the drawing).. or do you have
your ctb's set to screen that color? (if so, how do you screen a true
color in a ctb?).

but that still means having to do way to many steps if you need to
modify the size.

I'll just have to come up with another idea to fix our users needs, thanks.
C Witt

 

Interesting use of a solid hatch.

 

- associative hatch is evil.. (don't ask why, it just is).

- trim would work, but what about making it bigger.. moving it etc...

 

yeah, i also hear that a lot about mtext, associative leaders, tables,
reactors, layer states, autosave.........maybe you're just not evil enough
yourself to use it ;-)

Actually, I think its more of a dependability issue than anything. Hatch
associativity seems to break at the most inopportune moments (susceptible to
Murphy's law).

And just in case there is confusion: HPASSOC set to "1" (or checked ON in
the hatch dialog box) is different than the "Associative Hatch" option found
under the Selection tab of the Options dialog that actually sets pickstyle
to 2 (which IS truly evil). Curse the programmer that came up with *that*
level of obfuscation.

That evil associativity thing would help with a lot of that (as long as it
is working).

both samples I showed you did most of that if HPASSOC was left at "1"

Y'know, superhatch using a block made of a masking solid and your hatch
pattern would do exactly what you want. And superhatch has none of that
pesky associativity habits, regardless of settings ;-).