Template Field Names behavior in BZR 5250

[Mark Jones]

Application: kicad
Version: (2014-11-02 BZR 5250)-product Release build
wxWidgets: Version 3.0.0 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.8.2,wx containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Boost version: 1.54.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

Hello, in the eeschema Preferences --> Schematic Editor Options --> Template Field Names tab, if I type in one initial field name and value, then click Add, the entry is added with a name of "fieldname" and value of "value" regardless of what is typed in.

Once the entry is in there, clicking it to select it, highlights it while the mouse button is down, but de-highlights it when the mouse button is released. So individual entries cannot be selected. Also, the cursor keys will not work to select a row when TAB-ing into the list. So the "delete" button will only remove the last entry added, in reverse chronological order.

When adding a second entry, it DOES display as a new entry, with the entered name and value, but ABOVE the "fieldname" entry.

Subsequent additions appear BELOW the 2nd entry, but always above the "fieldname" entry.

A screenshot is included to illustrate this behavior after adding four items.

Thanks and regards,
Mark

[Nick Østergaard (nickoe)]

I can confirm that it will add those default entires but if I try to edit (click a row and change the field in the textinputs below and hit enter) an element it will segfault. See the attached backtrace.

I can not make it deselect an entry by clicking it. I have to click on an empty area of the list.

Version: (2014-11-02 BZR 5249)-kicad Release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.9.1,wx containers,compatible with 2.8)
Platform: Linux 3.17.2-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.56.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[Mark Jones (heliosstudios)]

Interestingly, I just noticed that it is possible in Win7 to right-click an entry to highlight it. So if a few entries are added, then the "fieldname" entry right-clicked, it can be removed with the delete button.

[Nick Østergaard (nickoe)]

There is no right click context menu on my system.

[xzcvczx (xzcvczx)]

i can't reproduce this behaviour is this still occuring?

[Robin Whittle (rw-p)]

I had the same experience with (Windows 7 64 bit) 4.0.2-stable. The cause is that the user interface is confusing, to me at least.

My initial impression was that the two text entry lines "Name" and "Default Value" are where we put our desired text in, along with setting the Visible tick box or not, before clicking the "Add" button.

The way it actually works is that these three items edit the currently selected line, with the displayed data in the line not changing until a second line is selected (there may be no such second line at first), or until the OK button is clicked, which updates the line and closes the dialogue box some milliseconds later. The "Add" button adds a new line with the text items "Fieldname" and "Value", which can then be edited if that line is selected.

A recent nightly (2016-04-23 BZR 6710, Git c1f0ab9) has the same overall functionality via Preferences > Schematic Editor Options > Default Fields. However the user interface is simpler and less confusing to me. There are no text boxes - all editing is done in-situ in the selected line. In this context, it is easy to see that the "Add" button adds a new line with items as just described, and it is easy to guess that the initial state of these, as just described, is default text ready to be edited directly.

So I think this problem has been resolved in the latest nightly. I will leave someone else to decide whether this bug should be regarded as fixed.