Closed dotoritos-kim closed 1 year ago
I doubt this is correct logic. You have insert
map which is indexed by block name. There may be multiple inserts referring the same block, however you just continuously override stored value with the most recent one. Also inserts may be nested in other block with deep nesting level.
이게 맞는 논리인지 의심스럽습니다.
insert
블록 이름으로 인덱싱된 지도가 있습니다 . 동일한 블록을 참조하는 여러 삽입이 있을 수 있지만 저장된 값을 가장 최근 값으로 계속 무시할 뿐입니다. 또한 삽입은 깊은 중첩 수준으로 다른 블록에 중첩될 수 있습니다.
I wrote this logic because I only needed to check which block and layer and attribute definition the attribute corresponds to. And the properties need to pre-specify the layer. That way it worked correctly. If no layer is specified in advance, the attribute is assigned to the "0" layer.
이게 맞는 논리인지 의심스럽습니다.
insert
블록 이름으로 인덱싱된 지도가 있습니다 . 동일한 블록을 참조하는 여러 삽입이 있을 수 있지만 저장된 값을 가장 최근 값으로 계속 무시할 뿐입니다. 또한 삽입은 깊은 중첩 수준으로 다른 블록에 중첩될 수 있습니다.I wrote this logic because I only needed to check which block and layer and attribute definition the attribute corresponds to. And the properties need to pre-specify the layer. That way it worked correctly. If no layer is specified in advance, the attribute is assigned to the "0" layer.
I still cannot understand. Here you populate insert
map:
for (const entity of dxf.entities) {
if (entity.type === 'INSERT') {
this.insert.set(entity.name, entity);
}
}
The values here will be constantly overridden, since multiple inserts in a file can refer to the same block. So by the end of this loop, the map will contain just last insert
in a file for a given block. And later you use this quite random entity to get the layer and color from. And as I pointed before, an insert
may be nested in another block, so its layer and color may be defined by some outter insert
.
이게 맞는 논리인지 의심스럽습니다.
insert
블록 이름으로 인덱싱된 지도가 있습니다 . 동일한 블록을 참조하는 여러 삽입이 있을 수 있지만 저장된 값을 가장 최근 값으로 계속 무시할 뿐입니다. 또한 삽입은 깊은 중첩 수준으로 다른 블록에 중첩될 수 있습니다.I wrote this logic because I only needed to check which block and layer and attribute definition the attribute corresponds to. And the properties need to pre-specify the layer. That way it worked correctly. If no layer is specified in advance, the attribute is assigned to the "0" layer.
I still cannot understand. Here you populate
insert
map:for (const entity of dxf.entities) { if (entity.type === 'INSERT') { this.insert.set(entity.name, entity); } }
The values here will be constantly overridden, since multiple inserts in a file can refer to the same block. So by the end of this loop, the map will contain just last
insert
in a file for a given block. And later you use this quite random entity to get the layer and color from. And as I pointed before, aninsert
may be nested in another block, so its layer and color may be defined by some outterinsert
.
this.blocks
this.insert
Comparing the two, the correct layer data does not exist in this.blocks object. But the data I get with that seemingly unnecessary logic is getting the right layer.
And even if blockCtx is null, we need to find a definition outside of this block to specify the layer.
이게 맞는 논리인지 의심스럽습니다.
insert
블록 이름으로 인덱싱된 지도가 있습니다 . 동일한 블록을 참조하는 여러 삽입이 있을 수 있지만 저장된 값을 가장 최근 값으로 계속 무시할 뿐입니다. 또한 삽입은 깊은 중첩 수준으로 다른 블록에 중첩될 수 있습니다.I wrote this logic because I only needed to check which block and layer and attribute definition the attribute corresponds to. And the properties need to pre-specify the layer. That way it worked correctly. If no layer is specified in advance, the attribute is assigned to the "0" layer.
I still cannot understand. Here you populate
insert
map:for (const entity of dxf.entities) { if (entity.type === 'INSERT') { this.insert.set(entity.name, entity); } }
The values here will be constantly overridden, since multiple inserts in a file can refer to the same block. So by the end of this loop, the map will contain just last
insert
in a file for a given block. And later you use this quite random entity to get the layer and color from. And as I pointed before, aninsert
may be nested in another block, so its layer and color may be defined by some outterinsert
.
You are right, this logic is wrong. Looks like I'll have to make a new one.
Now, rather than finding a layer based on the last insert, we prepare and render the attributes for each insert element. If you follow the attrib's ownerHandle, insertEntity exists.
attrib shows that it is related to attdef and block. I realized that if I properly associate tag and name, I could get the right layer, and I implemented it. Please confirm.