On 31/08/2011 9:35 p.m., Wayne Stambaugh wrote: > On 8/31/2011 12:16 PM, hauptmech wrote: >> On Wed, 2011-08-31 at 09:23 -0500, Dick Hollenbeck wrote: >>> On 08/31/2011 08:31 AM, hauptmech wrote: >>>> >From the bzr log message is appears that fields not in the template list >>>> will be deleted on exit from the component edit dialog. Or read >>>> differently Fields with a null value and not listed in the template list >>>> will be deleted (which seems to be the behavior when I play with it...) >>>> >>>> >>>> I store quite a bit of component meta-data here in the fields which >>>> either gets dumped to the BOM for automatic purchase order generation, >>>> or get's manipulated via python scripts accessing the raw eeschema >>>> files. >>>> >>>> >>>> >>>> Presently the file format uniquely identifies each field with an id >>>> integer. So empty values for field name and field value are technically >>>> not a problem. At least this was my assumption and it seems a reasonable >>>> conclusion for anyone writing scripts against the .sch file. >>>> >>>> I happen to use the field name as a key for some things and so they are >>>> unique, and non-null in my case. However there are lots of good reasons >>>> to stick a null in the field value and automatically stripping fields >>>> with a null value string would be undesired. >>>> >>>> I just noticed that if one of my field names is in the template it get's >>>> shuffled in the order. Also template fields get inserted before existing >>>> fields, and this order is being propogated to the field ID in the >>>> file... This will break things external to eeschema. I don't mind if >>>> they get displayed in a different order on screen but changing the ID in >>>> the file is very bad so the source of that should be tracked down and >>>> fixed. >>>> >>>> Regarding the fields template: In my opinion this should only be used >>>> inside the library component editor. Once a component is in the library; >>>> the component is *itself* a template for adding information to the >>>> schematic. I don't think we want to be 'automatically' modifing the >>>> components, making assumptions about the library creators intentions. >>>> >>>> I hope this is useful. >>>> >>>> -hauptmech >>> Two weeks of my time wasted. >>> >>> Sheesh. I really cannot agree with a single thing here. >>> >>> Sorry. >>> >>> Life is too short for this. >>> >>> Use the template fieldnames, put all your fields in there, every last one of >>> them, then if they are blank, they go away. Search for your fields by >>> name. >>> The number is going away, period. >>> >>> Dick >> I can migrate the metadata in my libraries from what they are now to >> key-value pairs in a new file format. And I can deal with that file >> format not handling null strings. >> >> But it's a bit rough on those of us using kicad to pull the rug out from >> underneath us by jiggering the existing file format. If you aren't >> releasing the next stable version until after there's a new file format, >> fine. But otherwise... ouch. > The the addition of field templates did not change the current file format > AFAIK. What I'm not sure of is if you define a field in library component > that > it's value is copied into the schematic component field when that field name > is > already defined in the template list. As for the forthcoming file format, it > should be transparent to the user that the file format has even changed. Hmm, I hadn't payed attention to the field template when it was introduced because it's not useful to me. The present stable version has the same behavior:
When a template field matches an existing field, and component properties are edited in eeschema, it inserts the existing field at the beginning of the non-reserved ones (id 4) and re-numbers all subsequent fields. Subsequently generating a BOM shows that the components fields are scrambled because the BOM generation uses ID rather than the field name to organize columns. ... Apparently as long as I leave the field templates empty it leaves the component fields in the same order as read which is why we haven't noticed any problems during board production. Now that I know the devil and it's nature, I'm happy to let it lay where it is. Under the specific conditions I use it, it does not damage the libraries, schematics, and production scripts I use, so it's not a problem for me. You guys should consider putting a warning on the field templates form though until the new format comes. Regards, Hauptmech > Wayne > >> Hauptmech >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp