roger_irwin wrote:
> --- In [email protected], "apluscw" <[EMAIL PROTECTED]> wrote:
>
>
>>I think there should be the means of setting the definition for
>>those fields globally across an entire sheet or hierarchy.
>>
>>You may want to see my previous posts on this topic.
>>
>>apluscw
>>
>
>
> Or perhaps there should just be an unqualified list of name/value
> pairs for all component properties, with some names (such as "Value")
> being considered reserved words?
>
Hmm, in effect this is allready being done. When assigning values to the
fields it is possible to rename the field. It is placed in the files as
an alias name at the end of the line but has the same effect as a list
of name/value pairs.
In the property editor the field name will subsequently show the alias
value. However, the actual form of the property editor means that these
extra fields are limited to to a max of 8. Perhaps in the future we
could have a grid of names values.
With the possibility of making list of name value pairs, it remains only
at the convinience of the users to agree on values in order to
facilitate the exchange of component libraries, However this is a bit
premature as at present it does not appear possible to define the
components at the library edit level.
In the meantime here are the names I am using:
Description : Usually additional qualifiers
eg for a cap: 10V low ESR 500mA ripple
Manufacturer : Manufactirers and part codes
DigiKey : Digikey part code
RSComps : RS part code
Farnell : Farnell part code
and of course we could go on with Conrad Distrelec etc etc. But of
course we run into the problem of the number of fields!
From my experience with Target, 2 things I would not do is a) Include
price info, it is too unreliable and hence just clutters things up
without being used. b) Do not put language variants. The information
tends to be almost identical but with different name descriptions it
make parsing the data from other programs a nightmare.
