← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema Default Library Field Names

 

--0016364d2009affde804814e1366 Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

I have attached a preliminary patch for adding FieldName support to
.pro project files. I have kept the external and internal number
referencing the same, so FieldName4 is the first user field name.

All comments are welcome!

A couple of notes:

(1) It only tries the first 16 fields (as is normal for KiCad) but
might be limiting. Perhaps I should change it to carry on until there
is a missing FieldName, just how LibName operates

(2) The GetDefaultFieldName and SetDefaultFieldName are public members
of the WinEDA_SchematicFrame class. But that means having to generate
a lot of frame pointers throughout the code through wxGetApp() which
seems a bit ugly. Any suggestions about moving them to somewhere more
sane would be welcome!

Tested on WinXP, and against SVN Rev 2434.

Best Regards,

Brian.

On 2 March 2010 11:05, Brian Sidebotham <brian.sidebotham@...> wrote:
> On 2 March 2010 03:25, Wayne Stambaugh <stambaughw@...> wrote:
>> Brian Sidebotham wrote:
>>> On 1 March 2010 21:23, Wayne Stambaugh <stambaughw@...> wrote:
>>>> Brian Sidebotham wrote:
>>>>> Hi,
>>>>>
>>>>> I have been looking at doing a patch to allow a list of default field
>>>>> names to be defined for eeschema's libedit.
>>>>>
>>>>> Problem: When creating new components with additional information,
>>>>> such as ordering codes and manufacturer part numbers, etc. you will
>>>>> currently need to edit the field names yourself for every component.
>>>>> This can quickly become tiresome.
>>>>>
>>>>> You could start with a blank part that has been saved to a library
>>>>> with the field names defined, but this means that you cannot use the
>>>>> New Component mechanism in libedit to create a new component.
>>>>>
>>>>>
>>>>> Proposal 1: Would be for me to do a couple of patches to eeschema to
>>>>> add this support to the project file structure:
>>>>>
>>>>> (a) Add Default Field Name support in the project file (e.g.
>>>>> DefFieldName0=3DManufacturer, etc.)
>>>>> (b) Add Editing of the default field names in the GUI.
>>>> Brian,
>>>>
>>>> I like proposal 1 personally because that is how I work. =A0It would b=
e
>>>> nice if your default field name editor was capable of applying the
>>>> changes to existing components in a schematic as well as any new
>>>> components. =A0Even better would be a simple grid editor with fields a=
s
>>>> columns and components as rows so that you could populate your user
>>>> defined fields in mass instead of one component at a time. =A0I'm just
>>>> throwing these ideas out to get people thinking about it.
>>>
>>> Hi Wayne,
>>>
>>> Thanks for the quick response. The default field names will be applied
>>> to old and new components via the field edit dialog that Dick has
>>> already written. This is used when you [E]dit a component in the
>>> schematic, and when you are creating a new component.
>>>
>>> At the moment, this dialog sets the default field names by simply
>>> making a string out of Field and the field number (N) as a suffix.
>>>
>>> I propose that instead, a list of default names is created as a
>>> project preference and read much like the library name list. If there
>>> is no custom default name, we can still drop back to the standard
>>> default of FieldN.
>>
>> This sound like a reasonable approach.
>>
>>> The grid based editor as you suggest would be a great, that would make
>>> stuffing these fields with values a lot less tedious. Handy when a
>>> part number field depends on the components value, etc.
>>>
>>> This is actually a bit of a pre-cursor to me wanting to add heavy
>>> symbol support into KiCad, which also really requires aliases to be
>>> improved too. I think Jean-Pierre has been doing some work in this
>>> area, trying to get rid of the .mdc library files.
>>
>> I haven't looked at JP's changes yet. =A0I was the one who originally
>> proposed getting rid of the .mdc file. =A0I got a little side tracked wi=
th
>> all of the things I was working on. =A0I'm almost done with my new
>> EEschema find dialog work. =A0Once the next release is out, I'll commit
>> the new find work then I'll revisit getting rid of the .mdc file. =A0If =
I
>> remember correctly, I wasn't really happy with changes to the component
>> library file format using my original concept. =A0Then Dick started
>> working on his DSN lexer so I thought I would wait until he got that
>> stabilized and then use it for the new library file format. =A0I'll see =
if
>> I can make getting rid of the .mdc file and moving to a DSN style file
>> format at the same time. =A0I'll make sure not to break reading the
>> current file format. =A0This shouldn't effect anything you are planning =
on
>> doing.
>>
>> Wayne
>
> Okay, that all sounds good. I will wait a few days for the dust to
> settle and any other opinions to surface and then I'll do a patch for
> supporting default field names in the project file.
>
> Best Regards,
>
> Brian.
>
 --0016364d2009affde804814e1366 Content-Type: application/octet-stream; name="rev2434_fieldnamesupport.diff"
Content-Disposition: attachment; filename="rev2434_fieldnamesupport.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g6jle8hi0

[Attachment content not displayed.] --0016364d2009affde804814e1366-- 




References