This project has moved. For the latest updates, please go here.

Get all objects from given layer

Sep 16, 2016 at 12:23 PM
I start using .net dxf Reader-Writer for a project. Creating dxf files with this library works fine and I'm very happy with this.
But now I want to read a dxf file and want to work with objects, especially Lines and Arcs, on a given layer.
Here is an example how I start investigating how to work with this lib.
         dxf = netDxf.DxfDocument.Load(FileName);
         dataGridView1.DataSource = dxf.Layers.ToArray();
         dataGridView2.DataSource = dxf.Lines.ToArray();
         foreach (netDxf.Entities.Line line in dxf.Lines) {
In my textbox allways appears the layer "0" as layer name allthough the objects are placed on different layer. What goes wrong?

Thanks for an answer.
Sep 16, 2016 at 3:56 PM
Assuming that, your dxf file is correct and the textBox1 variable references a TextBox control that has been initialized correctly, it should work.

Since you are trying to write multiple lines, your textBox1 should be initialized with multiline support and big enough to show all the lines, or at least you should show the vertical scrollbar to be able to scroll through all the items.

Sep 19, 2016 at 12:21 PM
Edited Sep 19, 2016 at 12:21 PM
Daniel, thanks for your reply.

the small function which was posteted does what it should do. I investigated a little bit and found that the issue is caused by the dxf file.

The dxf file I used was created with QCAD community edition which uses dxflib. With this file I can't get all references from a choosen layer. IF I use QCAD professional edition the result depend on how I save the drawing. If I save the drawing as dxf R15 using dxflib the result is the same as with the community edition. If I save the drawing as dxf R15 Teigha (what ever this means) I can read the dxf file and can get all references for a selected layer.

Fazit: It seems to be an issue with the dxf file. But where are the diffrences? Is it a bug or a feature? I'm not a dxf specialist. That's the reason why I want to use your lib.
If you like you take a look to the files. You will find them here

Sep 21, 2016 at 8:54 AM

I did some more investigations on my issue. Maybe it's a n issue with the lib.

I create an example using QCAD Community Edition. It contains the standard layer "0" and a new layer "Pane". A shape created on Layer "Pane" contains 4 lines and 4 arcs.

If I load this dxf file and get the references for the layer "Pane" I will find only the arcs in this layer. The lines are found on the standard layer "0". If I took a look to the dxf file I cannot find a reason why this happens. For me the dxf file look ok. But as I said before, I'm not a dxf specialist.

Can fix this? The example can be found here.

Thanks for your support.

Sep 22, 2016 at 7:13 PM
I have been looking through your files and the problem lies with them. While they are not wrong, strictly speaking, they do not follow what should be the correct way of writing the information of the lines in the entities section.

I will not go into details the details of the dxf structure, but the data that is common to all entities should be under the subclassmarker AcDbEntity, after that one or more subclassmarkers might appear with the data that is specific to the entities (for lines is AcDbLine and for arcs AcDbCircle). For unknown reasons, while the way the arcs are written is correct, the lines are not, for them the common data is under AcDbLine instead of under the AcDbEntity, and that data includes the layer information, and here is where your problem is.

They should fix that, they need to be consistent. The dxf documentation says that programs that write dxfs should not rely on the order that appear in the documentation, but this is not strictly true, sometimes it doesn't matter, sometimes it does, sometimes changing the order does not make sense and doing it can cause problems. I even found a case where the order in which the data appears in the documentation is wrong and will break the file.

Marked as answer by stebne on 9/23/2016 at 12:38 AM
Sep 23, 2016 at 8:37 AM

thanks for your support. Without this I won't had a chance to solve this.

The more I'm working with your lib the more I love it. Great work. Thanks.