Topic: ET LayDel surpress messages

[Joe Burke]

Looking at the ET lydelmrg routine. I wonder how it manages to surpress
the following message when it would otherwise occur?

"Hatch boundary associativity removed."

Example: delete an object which has a hatch associated with it.

Command: _erase
Select objects: 1 found
Select objects:
Hatch boundary associativity removed.

Example: delete a hatch object which is associated with an object.

Command: _erase
Select objects: 1 found
Select objects:
Hatch boundary associativity removed.

And a similar message regarding dimension associativity when an object
is deleted which is associated with a dimension.

Command: _erase
Select objects: 1 found
Select objects:
Dimension extension disassociated.

The reason I ask is because I have a few routines which may delete many objects.
They want to report at the end how many objects were deleted at the command line.
The annoying problem is the above messages spew to the command line after the
routine ends. So the report is sometimes lost somewhere above these messages.

Obviously ET LayDel avoids that problem somehow. The question is how? I've tried
every trick I can think of without success. Which leads me to think the solution
is something I've simply overlooked.

[dan19936]

Looked at Express Layer Delete, seems to just use entdel.

I tried (entdel (car (entsel))) on a hatch, no message.

Dan

[Joe Burke]

Dan,

Try that on a hatch which is associated with an object.

Command: (entdel (car (entsel)))

Select object: <Entity name: 7ef7d620>

Command:
Hatch boundary associativity removed.

[MP]

Vla-delete and | or Qaflags? <untested>

[MP]

Recreate hatch without boundary?

[Joe Burke]

Vla-delete and | or Qaflags? <untested>

Michael,

vla-delete and various qaflags settings I tried did not help. I see the ET command sets qaflags to 2 in some cases. But I'm not sure why within context.

[Jeff_M]

Hi Joe,
Even NOMUTT does not supress that notification. Strange.......must be something that can be done in ObjectARX.

[Joe Burke]

Hi Joe,
Even NOMUTT does not supress that notification. Strange.......must be something that can be done in ObjectARX.

Hi Jeff,

I've been tinkering with this issue for a couple months. NOMUTT was one of the first things I tried. Obviously no help.

Regarding ObjectARX, maybe. But the fact remains, the ET lydelmrg routine avoids the problem somehow using vanilla LISP. Which might lead you to think some command call is dumb enough to not return the annoying message. If so, I haven't figured out what it is.

[Jeff_M]

Hi Joe,
After I posted that I was able to go look at the lisp. I do see that it's just plain lisp now.

One thing that I'm finding as even stranger, I have Acad2002 open for a legacy project. I just drew a pline on a new layer, changed layers, added an associative hatch.... then in a flurry of try this, undo, try that, undo, try this other thing, not once did I see that message. I also have 2007 open, laydel is now a native command there.....I get that message using laydel there.....

[Joe Burke]

Jeff.

I'm using 2006. I don't have 2007.

Am I reading you right? It sounds like the issue I'm talking about has crept forward into 2007 given the former ET command LayDel is now a core function. If so, that makes some sense.

IOW, the old LISP function, whcih somehow avoids the problem, is on longer in play.

Just fishing...

[Jeff_M]

IOW, the old LISP function, whcih somehow avoids the problem, is on longer in play.

Correct.....

[dan19936]

I had originally done that - after running LAYDEL & then undoing. No message.
To recheck after your message I started a new drawing and tried again, this time there is a message.
I checked to see which vars that lydelmrg.lsp changes - the difference is just CMDECHO = 0.

Dan (using 2002 vanilla)

Dan,

Try that on a hatch which is associated with an object.

Command: (entdel (car (entsel)))

Select object: <Entity name: 7ef7d620>

Command:
Hatch boundary associativity removed.

[Joe Burke]

Well I'm still stumped regarding how ET LayDel manages to surpress the
"Hatch boundary associativity removed" message.

Keeping in mind, it seems those messages are not put to the command line
until after a routine ends.

I found the EXPERT variable set to anything other than 0 does surpress the
"Dimension disassociated" message when an object is deleted which was
associated with a dimension.

Frustated... but not ready to give up.

[dan19936]

Joe,

In 2006 does CMDECHO no longer suppress the message using entdel as it does for me in 2002? If that doesn't work, could you store up your messages until the end of the routine & then report using alert or perhaps doslib's dos_msgbox which can be closed automatically after a set time?

Here is a buffer routine:

Code: [Select]

;;;==========================================================
;;; Print to buffer
;;;   [text] - String values are stored in buffer & returned
;;;            Nil clears buffer & returns nil
;;;            T returns buffer
;;;
;;; Use (princ (xyz_princToBuffer T)) to print to text window
;;;==========================================================
(defun xyz_princToBuffer (text / dump)
  (cond ((eq 'STR (type text))
           (setq xyz_PRINCTOBUFFER_LIST (append xyz_PRINCTOBUFFER_LIST (list text))
                 dump xyz_PRINCTOBUFFER_LIST))
        ((eq nil text)
           (setq xyz_PRINCTOBUFFER_LIST nil))
        (T (setq dump "")
           (foreach x xyz_PRINCTOBUFFER_LIST
             (setq dump (strcat dump x))))
  )
  dump
)
Dan

Well I'm still stumped regarding how ET LayDel manages to surpress the
"Hatch boundary associativity removed" message.

Keeping in mind, it seems those messages are not put to the command line
until after a routine ends.

I found the EXPERT variable set to anything other than 0 does surpress the
"Dimension disassociated" message when an object is deleted which was
associated with a dimension.

Frustated... but not ready to give up.

[Joe Burke]

Dan,

I haven't had a chance to try the code you posted.

Here's what I found since my last post. I ran some tests on an another
machine which has 2002 and 2004. I now believe they operate the same
as 2006. If cmdecho is 0 the "Hatch boundary associativity removed"
message is suppressed in all three versions. Sorry if I led you to
think otherwise regarding 2006.

But that doesn't help unless I'm willing to let my routine end with
cmdecho set to 0, which I'm not.

I tried using a separate function for the report and then calling the
PrimaryFunction and the ReportFunction from a third function like this.

(defun c:Test ( )
  (c:PrimaryFunction) ;sets cmdecho to 0 and deletes objects
  (ReportFunction) ;how many objects were deleted, etc.
  (setvar "cmdecho" 1) ;if this is removed, messages are not displayed
  (princ)
)

Thinking the "Hatch boundary..." messages would be suppressed when the
PrimaryFunction ends. Nope, they are still displayed after Test function
ends.

Thanks for your help with this.