Hi Igor2,

I = think I agree with you that allowing multiple attributes with the same name= on a given object is a misfeature.

I didn't have involvement in developing this code, but have= a recollection that it came about around the time the new import code was = written - possibly as a part of it. When importing from schematics, attribu= tes on symbols get copied over to attributes on pcb footprints.

gnetlist allows (incorrectly imo), = multiple attributes with the same name, and I wonder if that might be the o= rigin of this behaviour in pcb?

Regards,

Peter= Clifton

On 14 Aug 2017 06:19, <gedau@= igor2.repo.hu> wrote:

Hi PCB developers,

what is the policy of PCB with redundant keys in attribute lists? (Same key= added multiple times with the same or different values.) Is this a bug or = a feature? If feature, do you plan to keep it?

I am working on a subcircuits in pcb-rnd and I want to use attributes to st= ore certain values. I am asking for clarification on how pcb mainline plans= to handle an attribute corner case in the future so that I can decide weth= er to maintain compatibility on this corner case or not.

Details (pcb mainline side)
~~~~~~~~~~~~~~~~~~~~~~~~~~~

I found that the low level attribute API permits the same key to enter the = attribute list multiple times:

=C2=A0- CreateNewAttribute() does this implicitly

=C2=A0- AttributePutToList() does this explicitly when enabled via an argum= ent

On the high level AttributePut() doesn't allow this and writing an exis= ting key the second time will replace the old value. Most of the code uses = the high level API so most of the code won't not allow multiple instanc= es of the same key.

I am a bit confused about what the plan was here. It seems the UI blocks th= e user from creating redundant keys, but the low level code has an explicit= feature from it and the .pcb parser also seems to allow it by using Create= NewAttribute(). In the same time AttributeGetFromList() will return only th= e first match so other than preserving and displaying the redundant entries= , the code won't be able to (easily) access them.

Why I ask (pcb-rnd side)
~~~~~~~~~~~~~~~~~~~~~~~~

In pcb-rnd I am removing support for redundant keys.

Rationale: I already upgraded the code so thate very object can have attrib= utes and I am starting to use attributes from the code, e.g. refdes and val= ue of a subcircuit would simply be on the attribute list. The only way such= programmed access would make sense is if we had our keys unique.

How this could affect compatibility
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

While removing it, I have two possibilities:

1. declare that it is a feature in pcb, and make some workaround (e.g. rena= ming redundant keys, like adding a /1, /2, /3 suffix), then probably remove= the suffix on save to .pcb for proper round trip; makes sense only if main= line devs say it's a feature in pcb

2. declare that it is a bug in pcb and simply keep only one of the redundan= t keys (no coding required); this would slightly break compatibility on the= very extreme case the user depended on adding redundant keys to a PCB, lay= er or element (these seem to be the only objects in pcb supporting attribut= es); or if mainline says it's a bug, and they fix it, we can keep 100% = compatibility

At the moment I favor 2., as I think 99% of pcb users don't even know a= ttributes exist so they didn't intentionally add redundant keys.

TIA,

Igor2