BLOCK parsing does not stop when ENDBLK is encountered about dxf-parser

[bzuillsmith]

Hmm interesting. I don't believe the dxf-parser looks at class names like AcDbBlockEnd as markers for where it is in the parsing process. It should have stopped reading the block at

0
ENDBLK

so something else must be going on. Thanks for posting the issue!

[mankyd]

Yeah, if you take a look, you'll see that when it encounters a 0 it calls parseEntities, and then continues to loop. It only breaks the loop when it gets to AcDbBlockEnd: https://github.com/gdsestimating/dxf-parser/blob/master/lib/DxfParser.js#L178.

I actulally have a fix for this as well as #2, though I don't have them in a state where I can submit a pull request. I'll work on this tonight.

[bzuillsmith]

Ah, you're right. Looks like block parsing is actually quite messed up. I was too hasty in testing that functionality. I'll post a fix for it soon. One thing I noticed in your example is that you have no handles for your blocks. I was using handles as property names in the output. Without handles, it outputs a single block with property name undefined.

I think AutoCad requires handles, but I could be wrong. If not, then I suppose we could use the name as the property name instead, or we could generate handles when they are missing.

[mankyd]

::shrug:: Not sure if they're required or not. This bit is output from OnShape, and loads fine into other software that I'm using. I'd vote either switch to name or create an new anonymous handle of some sort.