Topic: is SEQEND needed anymore ?

[mailmaverick]

Hi All

I have searched the internet and found that SEQEND is end of sequence of information for heavy polylines or blocks with attributes.

But I have also in some places that SEQEND may get extinct with newer versions of AUTOCAD.

Has it gone extinct or is it still in practice ?

[rkmcswain]

But I have also in some places that SEQEND may get extinct with newer versions of AUTOCAD.
Has it gone extinct or is it still in practice ?

It will still be needed as long as you need to create the entities that require them.
Where you are reading that they "may get extinct"?

[MP]

Weird, just last week I heard linked lists were on the endangered species.

[mailmaverick]

But I have also in some places that SEQEND may get extinct with newer versions of AUTOCAD.
Has it gone extinct or is it still in practice ?

It will still be needed as long as you need to create the entities that require them.
Where you are reading that they "may get extinct"?

http://forums.autodesk.com/t5/autocad-2000-2000i-2002-archive/trace-and-seqend/td-p/185701

Read Post No 3

[mailmaverick]

But I have also in some places that SEQEND may get extinct with newer versions of AUTOCAD.
Has it gone extinct or is it still in practice ?

It will still be needed as long as you need to create the entities that require them.

Which entities require SEQEND ?

[rkmcswain]

http://forums.autodesk.com/t5/autocad-2000-2000i-2002-archive/trace-and-seqend/td-p/185701

Read Post No 3

That post is over 13 years old, and it was just a guess.
SEQEND is still alive and well in AutoCAD 2016.

[MP]

I highly doubt seqends are going anywhere, that was merely John thinking out loud over a dozen years ago.

As for entities that that require seqends -- block inserts with attributes or any complex entity that is vertex based, like heavyweight polylines, 3d polylines, pface meshes etc.

[Lee Mac]

Which entities require SEQEND ?

Usually those for which DXF 66=1 (the 'entities follow' flag)

[irneb]

It's probably "possible" to change all these entity types to make use of dictionaries with sub-entities instead. But even if ADesk goes through all that trouble just to move a "linked list" structure from one storage position into another (for arguably little benefit, if not worse) ... they'd still need to keep SEQEND alive just for backwards compatibility.

So killing it off is rather a misguided idea. It works well for those entities where it's used, so leave it be. For those where it might not work so well (i.e. sub-entities not simply being a list of "owned" entities, but something like a tree structure of subents with their own sub-subents recursing ever deeper) you could always use dictionaries. And it's not as if SEQEND is actually "bad", it's at worst just as much extra bloat as a dictionary object attached to a container entity, usually a dictionary is lots of times more space hungry though.

[mailmaverick]

It's probably "possible" to change all these entity types to make use of dictionaries with sub-entities instead. But even if ADesk goes through all that trouble just to move a "linked list" structure from one storage position into another (for arguably little benefit, if not worse) ... they'd still need to keep SEQEND alive just for backwards compatibility.

So killing it off is rather a misguided idea. It works well for those entities where it's used, so leave it be. For those where it might not work so well (i.e. sub-entities not simply being a list of "owned" entities, but something like a tree structure of subents with their own sub-subents recursing ever deeper) you could always use dictionaries. And it's not as if SEQEND is actually "bad", it's at worst just as much extra bloat as a dictionary object attached to a container entity, usually a dictionary is lots of times more space hungry though.

Sorry irneb, due to my poor knowledge of LISP, I could not understand a word of it. Its like French to me.
I dont know what is dictionary, sub-entity, linked list, owned entity, tree structure, sub-subents, container entity etc..

Could you explain the above in this post so that we naives could get little enlightened on it.

[irneb]

It's not Lisp. It's the structure of the DWG file.

There's 2 ways an AutoCAD file stores complex entities (i.e. entities which are made by combining several, other entities):

• Have a link to a block/dictionary object, which then contains all the sub entities. Examples of this are blocks, objectscales, etc. Think of it as a pseudo entity placed in the DWG which simply refers to a definition which contains all the "real" entities.
• Start with the containing entity, followed by all sub entities with a SEQEND entity to mark where they stop. Examples of this are heavyweight polylines, 3d meshes, attributes per block instance, etc. Think of this as the normal entities just drawn normally, then grouped together by placing a "start here" and "stop here" surrounding pair of entities.

So in order to kill off SEQEND adesk would have to change the way DWG files are structured internally. I.e. all the entitiy types which used SEQEND before would need to use something similar to block definitions (i.e. those things called dictionaries). And thus this version of ACad would be unable to open old DWG files which still have SEQENDs inside them.

Edit: To show as a picture. Here's how the SeqEnd entity stores the vectors of a heavy weight polyline inside the DWG.


And then here's how it would have worked if it was stored using dictionary objects.

[MP]

i.e. all the entitiy types which used SEQEND before would need to use something similar to block definitions (i.e. those things called dictionaries).

Block definitions actually employ the same linked list technique as complex entities, using an ENDBLK sentinel rather than a SEQEND. That aside, nice explanation. Oh, and in before Lee.

[irneb]

Block definitions actually employ the same linked list technique as complex entities, using an ENDBLK sentinel rather than a SEQEND.

That's true yes, except for the first link. I.e. the instance "links" to the definition indirectly through the block's name. Pretty much the same situation as the 360 code which links to the object's dictionary collection object (if it has any dictionaries attached) - only with blocks the name refers to the name defined in the global block table instead of one for each entity.

[MP]

That's true yes, except for the first link. i.e. the instance "links" to the definition indirectly through the block's name. Pretty much the same situation as the 360 code which links to the object's dictionary collection object (if it has any dictionaries attached) - only with blocks the name refers to the name defined in the global block table instead of one for each entity.

I think the conversation may be vectoring off from what would help the OP to understand.

Block definitions employ the same technique as complex entities, using ENDBLK sentinels rather than SEQENDs.

In a block table the 360 entry is a pointer to the first member of the block definition*, a BLOCK entity.

*Block definitions are book ended by BLOCK and ENDBLK sentinel entities (AcDbBlockBegin and AcDbBlockEnd in object speak).

FWIW

[Lee Mac]

I may be mistaken, but I thought that Irneb was originally making the comparison between a block reference referencing the components of its block definition indirectly (as opposed to such components immediately following the block reference entity in the database?), rather than the sequence of components within the block definition itself, as MP is correctly describing, which follows the same structure as other complex entities.

Though I agree that this tangent discussion may be more confusing than beneficial for the OP.

Lee