User part fileds sometimes slide up into Datasheet field and below

[Clyde R. Shappee]

I have standardized on my user fields in making parts for parts list generation. I fill out all user fields and those I am not using I either enter ~ or N/A. I have seen that sometimes the first user field (in my case the Digikey order number) ends up in the Datasheet field. I am not certain if this always happens, or not.

I have tried entering ~ or a bogus file name in the data sheet field and this still happens, and the bogus entry is over written.

The part is fine in the module editor -- all fields are present and accounted for.

(I have yet to figure out how I desire to populate the data sheet field consistently).

This is seen in version 20100314 SVN-R2460. I am going to try 2010-05-05 today.

Clyde

[Clyde R. Shappee (clydes)]

The above behavior is what I see looking at the component in the schematic. In the generated parts list, The footprint is there, but the first user field is overwritten with the second.... and the rest slide up one. Sorry any confusion.

Clyde

[Dick Hollenbeck (dickelbeck)]

On 11/11/2010 09:39 AM, Clyde R. Shappee wrote:
> The above behavior is what I see looking at the component in the
> schematic. In the generated parts list, The footprint is there, but the
> first user field is overwritten with the second.... and the rest slide
> up one. Sorry any confusion.
>
> Clyde
>
>
Please try this with the latest version, which is not hosted in
subversion, but rather bzr at launchpad.net

Dick

[Clyde R. Shappee (clydes)]

This mention of bzr at launchpad.net is not clear to me... So I tried the latest version 20100505 from the usual place and it shows the problem.

Maybe Dick needs to spell it out in crayon for me as to exactly what to download. Sorry for my ignorance.

Clyde

[Dick Hollenbeck (dickelbeck)]

On 11/11/2010 02:41 PM, Clyde R. Shappee wrote:
> This mention of bzr at launchpad.net is not clear to me... So I tried
> the latest version 20100505 from the usual place and it shows the
> problem.
>
> Maybe Dick needs to spell it out in crayon for me as to exactly what to
> download. Sorry for my ignorance.
>
> Clyde
>
>

20100505

This would be May 5, 2010.

Why would you think this is a current version?

May I simply reproduce the text from the sourceforge.net URL:

https://sourceforge.net/projects/kicad/

shown again here:

Kicad EDA is an open source (GPL)
software for the creation of electronic schematic diagrams and printed
circuit board artwork. The WIKI is on sourceforge. The source code on
launchpad.net: https://launchpad.net/kicad

[Clyde R. Shappee (clydes)]

I went there, and all I could see was external downloads. I was looking for a Windows executable and found the May 5 version.

[Oscar Roberto Blanco García (orblancog)]

I have the same problem on KiCad version 2010-00-09 BZR 23xx for Ubuntu 11.04.
I have filled the custom fields but when i try to get the BOM, some content dissapears or it is replaced by the adjacent field. Even some of the footprint are missinterpreted as footprints, i'm not sure why that happend. Also, i don't know what happens if not all the components use any particular field.
Besides, the BOM doesn't use the custom names for the fields to organize the information, it seems that they should be always in the same order. I see in the library that they are named F0, F1, and so on, but custom names are just like aliases. Even in the .lib file, there is no F2 or F3 ( Module and datasheet default fields), not sure why.

This is what I use now:
F0 (Just the component identifier)
F1 (Component name)
F4 (Custom) Part Number
F5 (Custom) Description
F6 (Custom) Footprint-packaging
F7 (Custom) SMT/THT
F8 (Custom) Price
F9 (Custom) Distributor

[Oscar Roberto Blanco García (orblancog)]

Sorry, what i meant in second paragraph is:
"... Even some of the PART NUMBERS are missinterpreted as footprints. ..." Is it because it is just the adjacent field?

[Oscar Roberto Blanco García (orblancog)]

I came across with other problem, when you try to do an update from the library to the components, it doesn't update the fields info.

[Dick Hollenbeck (dickelbeck)]

Again, try the latest version from BZR.

[Oscar Roberto Blanco García (orblancog)]

I have fulfilled all information F0,F1,F2,F3... for every component and it worked !
BOM is OK
netlist with already associated module is OK.

But i still wonder why it didn't when some where blank.

[Dick Hollenbeck (dickelbeck)]

On 07/19/2011 04:11 PM, Oscar Roberto Blanco García wrote:
> I have fulfilled all information F0,F1,F2,F3... for every component and it worked !
> BOM is OK
> netlist with already associated module is OK.
>
> But i still wonder why it didn't when some where blank.

I can only talk about the most recent version, since that is all that can be
fixed, and because fixes have flowed into this area of the software over the
last year that may have already fixed what you are encountering.

Please say you are using the most recent version. Otherwise, say nothing, and
use that energy switching to the latest version.

[Clyde R. Shappee (clydes)]

I saw this today with version 2011-07-08-BZR-3044 Ubuntu.

As a clarification, what I saw was if I named a field but did not put in a value for it, it disappears.

To get around this, I put in bogus values

Digikey 12345-011-ND
Mouser Mouser <----- bogus one
Voltage 5V

[Dick Hollenbeck (dickelbeck)]

Comment #12 would be indicative of another problem. If you want help, you should ask for it first on the users mailing list at yahoo, not in a bug report with a moving target for the subject.

Bug reports are for reporting bugs in the *current* software.

There is still no evidence that the current software has the originally reported bug.
I suggest you use *template fieldnames* found under Eeschema's Preferences | Options | Template Field Names.

[Wayne Stambaugh (stambaughw)]

I just confirmed this on r3065. It turns out that the edit component in schematic dialog deletes any fields that have an empty value string when you click the OK button. So even if you set all the component field names using the field template dialog, the edit component in schematic dialog will happily remove them from the component if the field value is empty. I'm pretty sure this is not the behavior we are looking for. This also will cause the fields to shift up if any field(s) not at the end of the list has an empty value. If no one objects, I'll go ahead and make the change. Thanks Clyde for your clarification. It pointed me right to the problem.

[Dick Hollenbeck (dickelbeck)]

On 08/10/2011 10:24 AM, Wayne Stambaugh wrote:
> I just confirmed this on r3065. It turns out that the edit component in
> schematic dialog deletes any fields that have an empty value string when
> you click the OK button. So even if you set all the component field
> names using the field template dialog, the edit component in schematic
> dialog will happily remove them from the component if the field value is
> empty. I'm pretty sure this is not the behavior we are looking for.

Hold your horses, we should discuss this.

Why do you want an empty field in the part? You can get that data entry field
to come up again simply by having it in the template field name record.

There may be a bug, but I don't think this policy is it.

Dick

[Dick Hollenbeck (dickelbeck)]

On 08/10/2011 10:55 AM, Dick Hollenbeck wrote:
> On 08/10/2011 10:24 AM, Wayne Stambaugh wrote:
>> I just confirmed this on r3065. It turns out that the edit component in
>> schematic dialog deletes any fields that have an empty value string when
>> you click the OK button. So even if you set all the component field
>> names using the field template dialog, the edit component in schematic
>> dialog will happily remove them from the component if the field value is
>> empty. I'm pretty sure this is not the behavior we are looking for.
> Hold your horses, we should discuss this.
>
> Why do you want an empty field in the part? You can get that data entry field
> to come up again simply by having it in the template field name record.
>
> There may be a bug, but I don't think this policy is it.
>
> Dick
>

Why don't we start with a reproduce-able procedure which exhibits the bug? I
thought this was the purpose of the bug reporting database.

Simply having the fields disappear is not what the original bug report stated.
I intended for the fields to disappear when I wrote the code, if they were not
empty.

But bashing the Datasheet was not intended, and THAT is what this bug report is
about.

Dick

[Wayne Stambaugh (stambaughw)]

On 8/10/2011 11:55 AM, Dick Hollenbeck wrote:
> On 08/10/2011 10:24 AM, Wayne Stambaugh wrote:
>> I just confirmed this on r3065. It turns out that the edit component in
>> schematic dialog deletes any fields that have an empty value string when
>> you click the OK button. So even if you set all the component field
>> names using the field template dialog, the edit component in schematic
>> dialog will happily remove them from the component if the field value is
>> empty. I'm pretty sure this is not the behavior we are looking for.
>
> Hold your horses, we should discuss this.

Agreed. That's why I added the 'if no one objects' disclaimer. I was sure
this code wasn't added accidentally. I wasn't sure why it was added so I was
going to wait for feedback before proceeding.

>
> Why do you want an empty field in the part? You can get that data entry field
> to come up again simply by having it in the template field name record.

I've used the field name template since it's been implemented. That is why I
couldn't duplicate this behavior. I'm not sure everyone is aware of the
template field naming feature so this behavior will only show up when manually
adding fields.

>
> There may be a bug, but I don't think this policy is it.

I don't know if the behavior is a bug but it does catch you by surprise. Maybe
warning the user that any fields not in the template list without a defined
value will be deleted is the way to go here. This way the user has a chance to
add the field value before it is deleted. This is just one solution but I'm
certainly open to suggestion.

Wayne

>
> Dick
>

[Dick Hollenbeck (dickelbeck)]

The BOM generation code is alluded to in posting #1, but not specifically mentioned.
If this is a problem with the BOM, I'm not surprised. The current BOM generation code in EESCHEMA could be deleted in favor of code like Brian's python based BOM generator which works from the generic XML netlist export.

This realisation was where I came up with the idea of the parts_list in the new EESCHEMA design. The BOM generator in current EESCHEMA could be delete and removed as far as I am concerned. It will never work reliably, simply because all parts can have different fields, and there is no way to enforce that they all have the same fields. The new EESCHEMA parts_list design does enforce this, by its very nature, after all it is a spreadsheet.

[Wayne Stambaugh (stambaughw)]

On 8/10/2011 12:03 PM, Dick Hollenbeck wrote:
> On 08/10/2011 10:55 AM, Dick Hollenbeck wrote:
>> On 08/10/2011 10:24 AM, Wayne Stambaugh wrote:
>>> I just confirmed this on r3065. It turns out that the edit component in
>>> schematic dialog deletes any fields that have an empty value string when
>>> you click the OK button. So even if you set all the component field
>>> names using the field template dialog, the edit component in schematic
>>> dialog will happily remove them from the component if the field value is
>>> empty. I'm pretty sure this is not the behavior we are looking for.
>> Hold your horses, we should discuss this.
>>
>> Why do you want an empty field in the part? You can get that data entry field
>> to come up again simply by having it in the template field name record.
>>
>> There may be a bug, but I don't think this policy is it.
>>
>> Dick
>>
>
> Why don't we start with a reproduce-able procedure which exhibits the bug? I
> thought this was the purpose of the bug reporting database.
>
> Simply having the fields disappear is not what the original bug report stated.
> I intended for the fields to disappear when I wrote the code, if they were not
> empty.
>
> But bashing the Datasheet was not intended, and THAT is what this bug report is
> about.
>
> Dick
>
My bad. I didn't read the original bug report, only the last few entries.
Since that issue has been resolved, I will set the status back to fix
committed. I have confirmed the deleting of fields with empty values so I'll
open a bug report (if I can't find one that has already been opened) and we can
address the behavior there to avoid any confusion with this bug report.

Wayne

[Clyde R. Shappee (clydes)]

Dick said:

"Why do you want an empty field in the part? You can get that data entry field
to come up again simply by having it in the template field name record."

I do it as a place holder as I make parts... knowing that I am going to
fill in more information like the second supplier order information at a
later date.

Also, Dick said, and it is true:

"But bashing the Datasheet was not intended, and THAT is what this bug report is
about."

Yes that is the bug as originally posted, but more testing would have shown that any attribute with
any empty field will get bashed. So, I was not complete in my characterization of the bug. I
just reported what I saw then.

Wayne said:

"I've used the field name template since it's been implemented. That is why I
couldn't duplicate this behavior. I'm not sure everyone is aware of the
template field naming feature so this behavior will only show up when manually
adding fields."

And this feature is the way to go, but I learned of it too late. So I had a library
with some attributes and later decided to expand the set of them, so I tried using the
template. When I filled out the template with all of the fields I was ever going to use,
it made a mess of my library by adding duplicate attributes, if I recall correctly, so
I undid the template and have not used it.

If you want the bug re-written, Waynes post #14 explains the problem better than I have.

[Wayne Stambaugh (stambaughw)]

Clyde,

Dick's assessment that this bug report has been address because he fixed the data sheet field from getting clobbered is correct. I have opened a new bug report that address the recent discussion of fields with no value getting deleted when closing the component edit dialog. You can follow the conversation at https://bugs.launchpad.net/kicad/+bug/824592.

Wayne

[Dick Hollenbeck (dickelbeck)]

Clyde said:
> And this feature is the way to go, but I learned of it too late. So I had a library
> with some attributes and later decided to expand the set of them, so I tried using the
> template. When I filled out the template with all of the fields I was ever going to use,
> it made a mess of my library by adding duplicate attributes, if I recall correctly, so
> I undid the template and have not used it.
>
> If you want the bug re-written, Waynes post #14 explains the problem
> better than I have.

I don't agree that #14 is a bug. I don't want blank fields in my libraries or
parts.

I see the basis of agreement in your first paragraph however, if we can
reproduce that bug with current code. (But we also have to be open to the idea
that current code will not reproduce the problem.)
I will run a simple test on this in the next week.

Duplicate fields are not allowed, each fieldname must be unique now, therefore
when the dialog comes up, a given fieldname can come for only one of a number of
sources. One of those sources is the template fieldnames record. The record
supports initial values also, but I don't think I am using the optional initial
value yet.

Dick

[Dick Hollenbeck (dickelbeck)]

On 08/11/2011 01:17 PM, Dick Hollenbeck wrote:
> Clyde said:
>> And this feature is the way to go, but I learned of it too late. So I had a library
>> with some attributes and later decided to expand the set of them, so I tried using the
>> template. When I filled out the template with all of the fields I was ever going to use,
>> it made a mess of my library by adding duplicate attributes, if I recall correctly, so
>> I undid the template and have not used it.
>>
>> If you want the bug re-written, Waynes post #14 explains the problem
>> better than I have.
> I don't agree that #14 is a bug. I don't want blank fields in my libraries or
> parts.
>
> I see the basis of agreement in your first paragraph however, if we can
> reproduce that bug with current code. (But we also have to be open to the idea
> that current code will not reproduce the problem.)
> I will run a simple test on this in the next week.

I found and fixed a bug introduced by someone when they made SetName() block the
setting of m_Name when the field ID was -1.

This was in the library editor, field name editing. Template fieldnames were
not coming up in the library editor properly.

Now that that is fixed, I believe things are working again as I originally wrote
them.

Dick

[Dick Hollenbeck (dickelbeck)]

On 08/11/2011 01:17 PM, Dick Hollenbeck wrote:
> Clyde said:
>> And this feature is the way to go, but I learned of it too late. So I had a library
>> with some attributes and later decided to expand the set of them, so I tried using the
>> template. When I filled out the template with all of the fields I was ever going to use,
>> it made a mess of my library by adding duplicate attributes, if I recall correctly, so
>> I undid the template and have not used it.
>>
>> If you want the bug re-written, Waynes post #14 explains the problem
>> better than I have.
> I don't agree that #14 is a bug. I don't want blank fields in my libraries or
> parts.
>
> I see the basis of agreement in your first paragraph however, if we can
> reproduce that bug with current code. (But we also have to be open to the idea
> that current code will not reproduce the problem.)
> I will run a simple test on this in the next week.
>
> Duplicate fields are not allowed, each fieldname must be unique now, therefore
> when the dialog comes up, a given fieldname can come for only one of a number of
> sources. One of those sources is the template fieldnames record. The record
> supports initial values also, but I don't think I am using the optional initial
> value yet.

Clyde,

Line 38 of eeschema/template_fieldnames.cpp does save the template fields
*value* if it is non-blank, into the template. For the moment, this will always
be blank because the template fieldnames UI dialog does not allow editing the
"initial default value" of the template fieldname. But the template fieldname
does have such a thing as an initial value, currently only internally.

Imagine for a moment what would happen if the (value something) was present in
the ~/.eeschema file, where "something" was a reasonable non-blank initial
value, like '_'.
When you pull up your part fields, the template fieldname would show up and the
initial value should come in (if that fieldname was not already present with its
own non-default value).

Then when you exit the part property dialog, perhaps you could get the template
fieldname to 'stick', and be recorded into your part.

You could try this by simply editing the ~/.eeschema file and adding the text
(value _) to the FieldNames: entries, just after (field (name ABC)...
Don't know if this would be a reasonable workaround, but it might.

Again, don't know why you want a blank field in your parts. If it's for BOM
purposes, I'd simply use Brian's Python BOM generator and code it to work the
way you like. We have the EESCHEMA generic netlist export so that folks can do
things like BOMs external to Kicad in languages more suitable for scripting than
C++. I have a BOM generator that I wrote in Java that I use.

Dick