texupport

Under certain circumstances, the hatch command’s island detection feature does not work when mtext entities are contained within the area to be hatched.

Steps to reproduce:

   1. Create two mtext objects with this text (include a return after each word):  test centered text
   2. Set the width on both mtext objects to 0.
   3. Change the first mtext object to be middle centered justified.
   4. Edit the second mtext object:
   5. Select All
   6. Select the “Center” icon on the Text Formatting toolbar

   7. Both mtext objects look the same at this point.
   8. Draw a rectangle around each mtext object.
   9. Hatch inside each rectangle (allowing island detection).
  10. While the island detected around the middle justified text is correct, the border around the center justified text is incorrect.

Workarounds:
Either use middle justified mtext entities or do not use zero with mtext entities.

First Appeared: Unknown.  Bug didn’t exist in 2004, but is easily reproducible in AutoCAD 2008.
Status as of 2008SP1: Still reproducible

Submitted By: TommieR

Ever since bhatch was introduced in R13, it has had trouble finding the boundary of many areas which are bound by arcs or polylines with arcs.  This bug seems to be more troublesome the farther the linework is away from the UCS origin.  It appears to be worse still when the linework is far from the WCS origin (such as any geospatial drawing).  Over the past 14 years, the user community has come up with numerous workarounds to coax results from the bhatch command.  Unfortunately, no single workaround works in all cases.  Furthermore, none of these workarounds make sense to younger users who have never had to massage results from their software and have grown to expect applications to “just work.”  These workarounds are documented below.
 

Workarounds:

• If the linework is polylines, sometimes it helps to explode them before hatching
• If the linework is lines and arcs, sometimes it helps to convert them to polylines before hatching
• Sometimes it helps to temporarily set the UCS closer to the current view *
• Sometimes it helps to temporarily move the linework closer to the WCS origin
• Sometimes it helps to continuously cut the figure that won’t hatch into halves and hatch each half until a “leak” is found
• You should always to check the entities in question for an “extrusion direction” and if they have one, remove the extrusion direction with the express tools FLATTEN command. 
• HPGAPTOL almost never works

First Appeared: When bhatch was introduced in R13 (1994).  It’s possible that the hatch command from previous releases exhibited the same symptoms, but I simply can’t remember.
Status as of 2008 SP1: Still reproducible.

* I have written a short lisp command which automatically sets the UCS close to the current view, runs the bhatch command, and then sets the UCS back.  Although it still fails in many of the same situations that cause the “out of the box” bhatch command to fail, it definitely does a better job than the default command in many cases.  In particular, it sheilds the users from quite a few hatch errors when working in geospatial drawing files.  The code is as listed below.  I’ll add it to the downloads section as time permits.

;; bbh.lsp (Better BHatch)
;; ralph sanchez (rsanchez at texupport dawt net)
;;
;; As most users know, AutoCAD has trouble hatching anything but simple figures when working far from the WCS origin
;; The user community has come up with several workarounds and this code attempts one of the most common.
;; In short, it will temporarily change the UCS to the current view before executing the bhatch command.
;; As with all of the workarounds, it is not perfect and does not work in many situations.
;; It does, however, work better than the default bhatch command.
(DEFUN c:bbh (/ ucsorg ucsx ucsy)
  (DEFUN savars (sv0 / x)
    ;;excellent savars/revars functions from paul turvill
    ;;(prevents user ESC from killing variables)
    (COMMAND “._undo” “begin”)
    (SETQ svx1  nil
   olderr *error*
    ) ;_ end-setq
    (FOREACH x sv0 (SETQ svx1 (APPEND svx1 (LIST (LIST x (GETVAR x))))))
    (SETQ ucsorg (GETVAR “UCSORG”))
    (SETQ ucsx (TRANS (LIST 1 0 0) 1 0))
    (SETQ ucsy (TRANS (LIST 0 1 0) 1 0))
    (DEFUN *error* (msg) (revars))
  ) ;_ end-defun
  (DEFUN revars (/ x)
    (SETQ *error* olderr)
    (FOREACH x svx1 (SETVAR (CAR x) (CADR x)))
    (SETQ svx1 nil)
    (COMMAND “._ucs” “3p” (TRANS ucsorg 0 1) (TRANS ucsx 0 1) (TRANS ucsy 0 1))
    (PRINC)
    (COMMAND “._undo” “end”)
  ) ;_ end-defun
  ;;******************************************************
  (savars ‘(“cmdecho”)) ;’saves variables to be reset later
  (SETVAR “cmdecho” 0)
  (COMMAND “._ucs” (GETVAR “vsmin”) “”)
  (INITDIA)
  (COMMAND “bhatch”)
  (WHILE (= (LOGAND (GETVAR “cmdactive”) 1) 1) (COMMAND pause))
  ;;****************************************************** 
  (revars)
  (PRINC)
) ;_ end- defun

After joining lines or polylines within the PEDIT command, the SPLINE option can’t be run until the command is ended and reexecuted.

Steps to reproduce:

• Draw three lines which meet end to end
• Enter PEDIT (if peditaccept is turned off, hit “y”)
• Select J to join the segments
• Select S to spline the resulting polyline
• Notice that the command is exited

Workarounds: Exit the PEDIT command after joining the segments, then reexecute PEDIT and select S to spline.

First Appeared: 2007? (This bug is definitely not evident in 2004 and is known to exist in 2007.  Its status in 2005 and 2006 is unknown)
Status as of 2008 SP1: Still reproducible.

Thanks to Opie for submitting this report.