EESchema Find and Replace replaces with previous string.Problem

[Linda Huxley]

I'm running 4.0.0-RC2, but this problem occurred in several previous versions of EESchema, going back several years. I'm running Windows 8.1, but I don't think that that matters.

Steps to reproduce:
1. Create a new KiCAD project and open EESchema.
2. Place 3 copies of any component; in this example say 74ls122 from the 74xx library.
3. Open the Find and Replace dialog, and select "Search all component fields" and "Replace component reference designators".
4. Set the "Search for" string to "U?".
5. Click on Find, set the replacement value to "U1" and click on Replace.
6. Click on Find, set the replacement value to "U2" and click on Replace.
7. Click on Find, set the replacement value to "U3" and click on Replace.

The result is 2 chips designated "U1" and the third chip designated "U2". Instead, I would expect three different designations, "U1", "U2" and "U3".

This issue persists through closing and reopening the dialog in the middle of the above scenario too. There are many details about the above scenario which are illustrative only and which aren't necessary to reproduce the problem.

[Chris Pavlina (pavlina-chris)]

Confirmed. I'll get this one.

[Wayne Stambaugh (stambaughw)]

@Chris, thanks for taking this. I was looking at this yesterday and I can duplicate this issue on release builds. However, it seemed to work fine using debug builds. Maybe something is getting optimized away. I only verified this on Windows builds. The problem appears to be in the OnReplace() function which handles the combobox values and list entries.

[Chris Pavlina (pavlina-chris)]

It's definitely reproducible in debug builds on Linux.

[Chris Pavlina (pavlina-chris)]

Got it. The replace string in the SCH_FIND_COLLECTOR just isn't being updated if the user edits it after clicking Find.

[Chris Pavlina (pavlina-chris)]

Really should be 100% reproducible on all builds - it's just keeping old data. But the key is that you edit the Replace string after clicking Find and before clicking Replace.

[Wayne Stambaugh (stambaughw)]

Fix committed in product branch r6323. Please test this change and let us know if there are any issues.

[Linda Huxley (lhuxley)]

@Chris. Many thanks!

@Wayne. I assume you're talking to me... I've successfully built a Windows version of Kicad before. I'll try to do the build, it just may take me some time to get up to speed.

[Wayne Stambaugh (stambaughw)]

On 11/18/2015 9:02 PM, Linda Huxley wrote:
> @Chris. Many thanks!
>
> @Wayne. I assume you're talking to me... I've successfully built a
> Windows version of Kicad before. I'll try to do the build, it just may
> take me some time to get up to speed.
>
@Linda. You can always download[1] a nightly build from the kicad
website rather than trying to build from source. Until the stable
release, the nightly builds will be as stable (possibly more depending
on the commits) as the 4.0.0-rc builds since we are in feature freeze
which means no new features will be added to the development branch
until the stable release is done.

[1]: http://downloads.kicad-pcb.org/windows/

[Linda Huxley (lhuxley)]

@Wayne. Thanks, but when I checked, the latest nightly Windows build appeared to be a couple of days old, so I thought that I could shortcut the delay by building the latest revision myself. (Unfortunately, I couldn't get Kicad-WinBuilder to work.)

The nightly build finally updated. I was not able to reproduce the problem after installing revision 6324.

[Wayne Stambaugh (stambaughw)]

On 11/19/2015 9:31 AM, Linda Huxley wrote:
> @Wayne. Thanks, but when I checked, the latest nightly Windows build
> appeared to be a couple of days old, so I thought that I could shortcut
> the delay by building the latest revision myself. (Unfortunately, I
> couldn't get Kicad-WinBuilder to work.)

@Linda. The legacy Kicad-winbuilder is no longer supported. There is a
new kicad-winbuilder that uses the msys2 platform to build both 32 and
64 bit MinGW builds that can be found here
https://github.com/nickoe/KiCad-Winbuilder.

>
> The nightly build finally updated. I was not able to reproduce the
> problem after installing revision 6324.
>

Thank you for taking the time to download and install a nightly build
and the feedback.

[Linda Huxley (lhuxley)]

@Wayne. It was the Github version of Kicad-WinBuilder that failed. The PC that I'm using is used for many purposes and some of the installed programs and libraries on this PC might possibly interfere with the builder. (i.e. programs like Msys, Python, Cygwin, AVR tools, Xilinx tools, etc.) I'm not sure where to start to track down the problem, so I have posted a note on the builder forum.

[Wayne Stambaugh (stambaughw)]

Possibly your windows PATH contains paths to conflicting libraries.
Looking at some of the applications that you have listed, this is a real
possibility. Also, if you are performing a 64-bit build, the latest
version of boost doesn't work. I had to downgrade boost 1.57 and tell
the package manager not to upgrade it on my msys2 build platform. I
don't know if Nick has addressed this yet or not.

On 11/19/2015 10:22 AM, Linda Huxley wrote:
> @Wayne. It was the Github version of Kicad-WinBuilder that failed. The
> PC that I'm using is used for many purposes and some of the installed
> programs and libraries on this PC might possibly interfere with the
> builder. (i.e. programs like Msys, Python, Cygwin, AVR tools, Xilinx
> tools, etc.) I'm not sure where to start to track down the problem, so
> I have posted a note on the builder forum.
>

[Linda Huxley (lhuxley)]

Thanks Wayne. I tried your suggestions, but it looks like the problem is occurring just before the actual build of KiCad starts. (So your suggestions may yet prove useful.) While preparing this note, I figured out what the instant problem was. It's not really appropriate to continue with this discussion here, so I'll move over to the builder forum.