Group problem help

R2005:

I posted the drawing from an earlier discussion over in customer files.

I can erase all entities in the drawing.

Then use:
(setq grp (dictsearch (namedobjdict) "ACAD_GROUP"))
Or:
(setq grps (vla-get-groups (vla-get-activedocument (vlax-get-acad-object))))
and they will show 15 unnamed groups, each with a substantial count of entities.

How can I know to delete these if they don't show that they are empty using vlisp or autolisp functions?

TIA

Bill

 

One thing I have discovered about this is:

If I insert one of our CNC programs that has groups in it, into another drawing, that's when these extra unnamed groups are created. The other groups in the inserted drawing also be come *unnamed*.
These extra unnamed groups appear to be copies of the original groups.

HTH

Bill

 

Hi Bill,

Using 2004 here. Am I still missing something?

With the drawing you posted:

(defun celeteUnnamedGroups ( / groups nm )
(setq groups
(vla-get-Groups
(vla-get-activedocument
(vlax-get-acad-object))))
(print (vlax-get groups 'Count))
(vlax-for x groups
(setq nm (vlax-get x 'Name))
(if (vl-string-search "*" nm)
(vla-delete (vla-item groups nm))
)
)
(print (vlax-get groups 'Count))
(princ)
) ;end

Command: deleteunnamedgroups
28
0

With one named group added:
Command: deleteunnamedgroups
29
1

Joe Burke

 

; remove one entity groups too
(defun ALE_PurgeGroups ( / VlaObj)
(vl-load-com)
(or *AcadApp* (setq *AcadApp* (vlax-get-acad-object)))
(or *ActvDwg* (setq *ActvDwg* (vla-get-ActiveDocument *AcadApp*)))
(vlax-for ForElm (setq VlaObj (vla-get-groups *ActvDwg*))
(or
(< 1 (vla-get-count ForElm))
(vla-delete ForElm)
)
)
(vlax-release-object VlaObj)
)


--

Marc'Antonio Alessi
http://xoomer.virgilio.it/alessi
(strcat "NOT a " (substr (ver) 8 4) " guru.")

--

 

Using 2004 here. Am I still missing something? <<<

Joe,
Thanks for your interest.
I am not trying to delete unnamed groups.

This is what has been happening here:

When we insert a drawing of our CNC nest (these CNC drawings contain several parts and each part consists of a named "group" of multiple entites), into another drawing, the groups that are in the inserted drawing become unnamed AND an additional bunch of unnamed groups mysteriously show up in the current drawing. These additional groups SAY that they consist of multiple entities, so there is no way to pick them up for deletion as an empty group and no way to tell if they need to be deleted.
I can't delete all unnamed groups in the drawing because some of them are valid and we need to keep them.
It really appears to be a bug. One that's been around for a while.

Bill

 

Thanks Marc'Antonio Alessi,

But if I delete all groups in the drawing then I no longer have a job.

See my reply to Joe B.

Bill

 

Would your problem go away if the CNC drawings' parts were block definitions
instead of groups? We do that kind of thing (a drawing of all imaginable
kitchen cabinet elevations as blocks, that we stick into an
interior-elevations sheet, and from which we use the blocks), without any
difficulties. Not that it "answers" the bug, but it's another way of doing
it, unless you have a reason to be using groups instead of blocks.

Kent Cooper, AIA

 

Thanks Kent,

Blocks won't work for us.


Bill

 

So from what I gather from your post, you want to delete all unnamed groups that don't have any objects within them. If that is the case would this work? I just added a check to see if the count of the group was equal to 0 items, if so then delete.

Tim

(defun celeteUnnamedGroups ( / groups nm )
(setq groups
(vla-get-Groups
(vla-get-activedocument
(vlax-get-acad-object))))
(print (vlax-get groups 'Count))
(vlax-for x groups
(setq nm (vlax-get x 'Name))
(if (and (vl-string-search "*" nm) (= (vla-get-count x) 0))
(vla-delete (vla-item groups nm))
)
)
(print (vlax-get groups 'Count))
(princ)
) ;end

 

Thanks,
But the unnamed groups with no entities in them are not the problem.

It's the groups that are mysteriously created upon an insert of the CNC drawing that are the concern.

Bill

 

Try my function it remove ONLY 0 entities AND
1 entity groups.

I think that there is no reason to have a group
that refernce only to 1 entity.

if you modify:

(< 1 (vla-get-count ForElm)) to

(< 0 (vla-get-count ForElm))

you remove only 0 entities groups.

 

Bill,
even if it is a bug, autocad would do things consistently (fortunately)...
what i would do is:
1- insert only one group from the parent drawing to an empty current drawing
or create a drawing w/ one group inside it, then insert it in the empty
drawing
2- find out the two (or more) new groups just created in the current
drawings, compare
names and entitied inside each groups.
3- figure out how u can differentiate the good one from the bogus ones.
4- put the rule to delete the bogus ones in the code provided by Tim

hope u can find what u are looking for

mark

 

Bill,

Just to confirm what you said, "appears to be a bug". Using 2004.

In a new drawing (source drawing) with no groups defined I added two groups, one
named and one unnamed. I inserted source drawing into a new file with no groups
defined. Call it target file. Target file now contains two unnamed groups, *A3 and
*A4. Not good.

The only solution I can think of is maybe copying the Groups collection from source
file to target file. I haven't tried it. That might avoid what insert apparently does
with groups.

Joe Burke

 

Joe,
This appears to be different than what I am gettting.
I take a drawing with 2 groups (named or unnamed), insert it into another or blank drawing with no groups, and now the blank drawing has 4 groups in it, all unnamed.

I've got to do some more testing today as I have time.

Thanks

Bill

named and one unnamed. I inserted source drawing into a new file with no groups
defined. Call it target file. Target file now contains two unnamed groups, *A3 and
*A4. Not good.
<<<<

 

Thanks Mark,

I will do some more testing here to see if I can make some sense outof it.

Bill

 

Joe,
Let me expand on what I previously said:

I open a new drawing, I insert a drawing that has 2 groups in it. This insert is NOT exploded and is now a block.
Now, when I check the drawing for groups, I immediately have 2 unnamed groups in the drawing that are apart from the un-exploded block.
Then I explode the block and I have the 2 inserted groups in the drawing but they are now unnamed.

Weird huh?

All these groups that show up in the "ACAD_GROUP" have their own unique ename but these new unexpected groups look like they may be some sort of copy of the inserted groups. The only difference is, they do not respond to "erase" "all" command and when I look at their contents, they still show that they contain entities even after all entities in the drawing are erased.
<play twilight zone music here>

Bill

 

Well, what would you suggest should happen in the event that the
'target' file already contained a named group with the same name?

We've all seen the 'duplicate definition of block <name> ignored'
message uttered by the INSERT command, right? And so what's
conceptually different about group name collisions?

 

Mark,
even if it is a bug, autocad would do things consistently (fortunately)...<<<

I'm not so sure it's actually a "bug" per se as it appear that the Autodesk people are aware that these "zombie" groups exist.
The reason I think they know is that even after they appear in the drawing after an insert, they do not show up with (entlast) even though they should be the last entity when the insert is deleted. Also, they do show up in the Group Dialog Box at all. The only real bug that they impose by being there is that now you have unpurgable group entites that no doubt use memory (but what the hey, memory is cheap now days) .
1- insert only one group from the parent drawing to an empty current drawing
or create a drawing w/ one group inside it, then insert it in the empty
drawing.<<<
It doesn't matter how many or how few groups you have in the drawing that you insert, you get a "zombie" for each group inserted.
3- figure out how u can differentiate the good one from the bogus ones.
4- put the rule to delete the bogus ones in the code provided by Tim<<<
There appears to be no way to determine a "zombie" from a valid group. They look just like us!!!

Thanks for the input.

Bill

 

The only real bug that they impose by being there is

I have found drawings with 80.000 null groups > 10 Mb with
all entities deleted.

If you search on this NG you will find many messages
on this subject from R14 days.

It is a bug!

Have you tried my function?


--

Marc'Antonio Alessi
http://xoomer.virgilio.it/alessi
(strcat "NOT a " (substr (ver) 8 4) " guru.")

--

 

Bill,
They look just like us!!!

maybe some voodoo magic

from within a group, investigate each group code 340
to see if the entity actually exists, else remove it from the group
(if (null (entget (cdr (assoc 340 groupobject))))(vl-remove ...
then, after all is processed, if group ends to be empty, delete the group
too.

actuall i had a similar problem, and i successfully used the old fashoned
way ...
(command "._-GROUP" "R" groupname entityname ...

BTW, a group is not an entity, so entlast will not select the group,

HTH
mark