eeschema "Find" function (Ctrl+F) fails, unless wrap-around

Bug #1199689 reported by Thiadmer Riemersma
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KiCad
Fix Released
Low
Wayne Stambaugh

Bug Description

In eeschema, when locating a component, say "C5", with the Find function (Ctrl+F), eeschema may or may not find it. If it finds C5, it may not find C4, for example. When a label occurs twice in a sheet, Ctrl+F may find one, but not the other.

These problems disappear when you activate the "Wrap around end of search list".

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

You have accurately described the expected behavior of the wrap option. Searching starts at the last found object in the schematic or the first object in the schematic if no previous search has been performed. The object order in the schemaitc is typically the order in which the objects were placed in the schematic. Therefore, the searching may not be alphabetically which may be confusing to some. The disabling the wrap option is handy when you are doing wildcard searches (C*) and do not want to search for objects that were already found. I am reluctant to change this behavior for this reason. You are the only second or third person that I can recall having an issue with this.

Revision history for this message
Thiadmer Riemersma (thiadmer-riemersma) wrote : Re: [Bug 1199689] Re: eeschema "Find" function (Ctrl+F) fails, unless wrap-around

Hello Wayne,

I have done a few more tests. There really is a bug in the code (though it
may be more subtle than I described initially).

Assume that I have a schematic with 17 capacitors an a bunch of other
components. The capacitors are sequentially numbered C1 to C17. (This is
not hypothetical, this is an actual schematic)
These are my scenarios:

1) "match whole word" is on, "wrap-around end of search list" is off.
Whatever reference designator I type in, whether it is C1 or R4 or D1, it
is not found.

2) "match whole word" is off ("wrap-around end of search list" is still
off). When searching for C1, it finds C1, C10, C12, C13, C14, C15, C16 and
C17 (there are only 17 capacitors on the particular board). It has not
found C11, though. When re-doing Ctrl+F and typing C2, it is not found. Any
item that appears only once, will not be found.

3) "wrap-around end of search list" is on ("match whole word" is still of).
Now, when typing C1, it finds all components matching C1 (so C11 included).

So, my hypothesis is that the component at the end of the list is excluded
from the search if "wrap-around end of search list" is off.

Also, in my tests, after turning "wrap-around end of search list" on, I had
to restart eeschema for the option to be effective.

Regards,
Thiadmer Riemersma

Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

Confirmed by me too.

It's actually pretty chaotic.

With "Match whole word" checked it never finds anything unless "searcha all component fields"

"Search all component fields" makes no difference to what it should do. It searches them either way.

Wrapping the search sometimes works, and sometimes doesn't. It also depends on the setting of "search all component fields" even though it searches all those anyway.

I can't find any fixed and repeatable pattern but there's definitely something wrong.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

I need two additional pieces of information. What version of KiCad are you using? Please select "Help->Copy Version Information" from the menu and paste it into you reply. Also, is your schematic a hierarchy (has sheets)?

Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

I'm using BZR4011 stable on Win 7.

No hierarchy, just a single sheet.

Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

I've done some more playing and pinned it down a bit better. There seems to be a few different things going on which confuses things.

Firstly, "Search all component fields" doesn't do what I (at least - maybe not others) would expect. With it *not* checked, it searches the reference and the value fields. I guess this is the intended behaviour though to me it should only search the reference. With it checked, it searches the footprint and the datasheet fields in addition. I guess this could also be intended.

However, when it is *not* checked, it also searches any custom fields. I would guess this is not intended as it's a bit confusing until you realise what is going on.

But the worst part is this...

When you select or deselect "Wrap around..." it doesn't actually take effect unless you also change one of the other checkboxes. If it's going round in circles finding components, and you uncheck the box, it carries on going finding them. If you now select (or deselct) a different checkbox, it now does what it should. The same thing happens on unchecking it. I think this is the root of the confusion and it often not finding things.

Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

dialog_schematic_find.h

#define FR_MASK_NON_SEARCH_FLAGS ~( wxFR_DOWN | FR_SEARCH_WRAP | FR_NO_WARP_CURSOR | FR_REPLACE_ITEM_FOUND )

Surely the FR_SEARCH_WRAP shouldn't be in there?

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

Thank you for the additional input. You are correct. When "Search all component fields" is not checked, only the component reference and value fields are searched. When it is checked, all of the component fields including the reference and value fields are searched whether they are visible or not. At least that was the design intent. I could have added check boxes to search the reference and the value fields separately but the find dialog was getting a little busy for my tastes. I suppose I could revisit it at some point if it continues to cause grief for users. However, it should not search for any custom fields when it is unchecked. I'm not sure whats going on here but I'll take a look at it and the wrapping issue when I get a chance. I'm kind of busy right now so it might be a couple of weeks until I can get to it.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

On 7/11/2013 4:14 PM, Chris Gibson wrote:
> dialog_schematic_find.h
>
> #define FR_MASK_NON_SEARCH_FLAGS ~( wxFR_DOWN | FR_SEARCH_WRAP |
> FR_NO_WARP_CURSOR | FR_REPLACE_ITEM_FOUND )
>
> Surely the FR_SEARCH_WRAP shouldn't be in there?
>
It should be in there. This is just a case of poor naming on my part.
SEARCH should really read STRING_COMPARE. This is used to check if any
of the flags that would effect the string comparison routine have changed.

Changed in kicad:
assignee: nobody → Wayne Stambaugh (stambaughw)
Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

That's what I thought. So after you've done a search, and it's found the last one, if you now check "Wrap..." it won't search again until another checkbox is changed. Instead it just stubbornly sits there finding nothing because FR_MASK_NON_SEARCH_FLAGS makes it ignore the change introduced by the new state of the "Wrap..." checkbox. The only way it will search again is if something else changes.

For the same reason, if you are searching and it's going round in circles (Because "Wrap..." is checked), unchecking it doesn't stop that because the changed state is ignored, again because of FR_MASK_NON_SEARCH_FLAGS.

Obviously I don't know the software so I have no idea if this has any impact on other sections but removing FR_SEARCH_WRAP from that define does indeed fix the problem and it now searches properly (except for always searching the custom fields no matter what the settings).

Revision history for this message
Thiadmer Riemersma (thiadmer-riemersma) wrote :

I have tested with BZR 4011-stable and with 4241-testing, both on Windows
XP.

In both releases, when I have only "match whole word" set (and no other
options, specifically not "wrap around end of search list", eeschema won't
find reference designator that I type in.

When I turn "match whole word" off, eeschema finds all matching components,
except one (presumably the one that was added last, but I have not tested
this yet).

Regards,
Thiadmer Riemersma

Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

When it gets to SCH_FIELD::Matches, m_id is correctly set for the mandatory fields. For custom fields it's set to -1 which that function isn't expecting.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

On 7/12/2013 1:08 PM, Chris Gibson wrote:
> When it gets to SCH_FIELD::Matches, m_id is correctly set for the
> mandatory fields. For custom fields it's set to -1 which that function
> isn't expecting.
>
This is unexpected. Custom field IDs should start at MANDATORY_FIELDS
(4) and increment for each custom field. At least that's how it's
documented in template_fieldnames.h. I'll take a look at it and see if
I can figure out how the custom fields are ending up with an index of
-1. Thanks for help.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

On 7/12/2013 1:08 PM, Chris Gibson wrote:
> When it gets to SCH_FIELD::Matches, m_id is correctly set for the
> mandatory fields. For custom fields it's set to -1 which that function
> isn't expecting.
>
I just committed a patch to the testing branch (r4242) which should fix
the issue when the wrap past end of list option changes state and when
components have custom fields. When you get a chance, please let me
know if you find any problems before I close out the bug report and add
the patch to the stable branch.

Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

It's definitely fixed the issue with searching the custom fields. That's easy to test.

It also appears to have fixed the wrap issue too but that one is a bit more difficult to test properly. So far I am unable to trip it up. It always seems to search properly now.

Nicely done Sir.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

On 7/14/2013 2:31 PM, Chris Gibson wrote:
> It's definitely fixed the issue with searching the custom fields. That's
> easy to test.
>
> It also appears to have fixed the wrap issue too but that one is a bit
> more difficult to test properly. So far I am unable to trip it up. It
> always seems to search properly now.
>
> Nicely done Sir.
>
Thanks for quick reply and all of the help. I'll wait a few days and if
I don't hear anything else, I'll apply the patch to the stable branch.

Revision history for this message
Chris Gibson (chris-w-gibson) wrote :

I've now spent a couple of days using the search function extensively on several different schematics and it's not let me down once. I would say it's fixed.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

On 7/16/2013 4:17 AM, Chris Gibson wrote:
> I've now spent a couple of days using the search function extensively on
> several different schematics and it's not let me down once. I would say
> it's fixed.
>
Great! Thanks for the testing. I'll apply this patch to the stable
branch in the next day or so.

Changed in kicad:
status: New → Fix Committed
Revision history for this message
Martin Errenst (imp-d) wrote :

r4024 stable

Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.