This is I think a new one, but our standard advise may still apply. Try deleting these two directories and then restart fritzing as it is possible that the parts database is corrupted. The instructions to do that are in this thread in my post from feb 28. I’m runnning Fritzing on Win7 64 and search works fine for me so it does work.

Unfortunately I’ve already tried that more than one time.
And I tried again now deleting both folders.
The problem is still there on both pc’s: no search text field and duplicate “mine” and “search” bins…

Since I’m a computer developer, I’m now trying to download the source files from git and compile them so I can see the bug from “the inside” Unfortunately this process is not very straightforward, I can compile the software inside QTCreator, but the program crashes at startup…

Yes compiling from source is a challenge. I have a linux system that I’m trying to come up to speed on development on, but there are issues. As Sublimeartistry suggested QT version 5.6 is the place to start as it is the version the .9.3b was built with. I assume you have found the build instruction on

There is also an issue in the llibgit2 release, 23.4 (already fairly back level) doesn’t work properly, I’m going to go back to 23.3 and see if that helps (and then try and move forward towards a more current release). We are trying to get development back on track (and being able to build successfully would be a good start ) so more people doing development is desirable. That said I’m surprised that Win7 is giving problems, I have .9.3b on 3 different Win7 machines (2 64bit and one 32bit) with no issues and we haven’t had complaints in a few months. Win10 has had patching issues in the past but Win7 has been stable. One common problem is not waiting long enough on initial startup. The first thing Fritzing does is get the parts updates from github and it appears to hang (as there is no progress bar displayed). If you interrupt that, it usually corrupts the database and you need to delete the directories and start again.

Yes I’ve followed the build instructions and it builds, but does not run as it crashes at startup (pls see Run inside QTCreator ).
I can confirm that on my win7 64 bit I have this same issue, the same as in the win10 64bit machine.
And I’ve not interrupted the updates from github.

Yes I’ve followed the build instructions and it builds, but does not run as it crashes at startup (pls see Run inside QTCreator ).

Yep, I saw that thread. Its likely that changing down to QT 5.6 will help (at least that works on Ubuntu 16.04 desktop linux) but as far as I know you are the first (at least lately) to try Windows so you are blazing new ground. The head of the dev tree was broken due to a new gerber implementation which I think has new been reverted. There is a checkpoint at the .9.3b release, but it didn’t work any differently when I tried that on Linux (the same parts update issues occurred which is why I think that is a libgit2 version issue). As noted building a release which gathers all the libraries together fixes that problem, but I’d rather have a working version in QT creator to use.

Long story short, the program compares the filename of the selected bin to some “special” names, including the search bin. But the drive letter is lowercase in the “SearchBinLocation” variable and uppercase in the bin->fileName(), so all the “compares” failed!!!
This issue exists all over the source code, not only related to the search bin. Maybe it’s causing other issues other than the missing search field.

Unfortunately I still have the problem that at each startup some bins get duplicated…
Inside the windows registry, where QT saves application settings, those duplicated bins are actually duplicated inside the “bins2” registry key…

I thinks that also this problem could be caused by some case sensitivity issues somewhere in the code; unfortunately the codebase is big and I’m not familiar with it…

Is it possible that you have an odd setting on your machines that is enabling case sensitivity when it isn’t normally on? Otherwise this bug should be hitting everyone that runs Windows and it isn’t, most people run the binary without problem. I do know of a similar problem but it is the other way, works on Windows but not on Mac or Linux. If the case of a svg filename in the fzp file is different than the case of the file in the file system Windows works (because filesystem case is preserved but ignored otherwise) but on Linux (and I expect MacOS too) the part fails because filename case matters and it can’t find the svg file. It would be good to clean up the code but as you say it is likely to be a lot of work. Hopefully you will like Fritzing once you get it working because we could sure use more people that can help develop, so if we can help just ask!

I understand what you say; I’m one of the few on windows with this problem. Reading other pertinent topics on this forum it looks like that for other people this problem appeared after a windows update. So maybe that’s why some people has the issue and some other do not have it,
By the way, the two pc’s with the problem are completely different: the win7 one is my “work” PC, installed a couple years ago by a corporate technician of the company I work for and I cannot modify any setting on it, while the win10 pc is my pc and I’ve installed it one year ago more or less.

The only difference of the path Fritzing compares is the drive letter, the rest of the path is correct.

and in that page search for “QString QFileInfo::absoluteFilePath() const” (no quotes of course): it’s the method used by Fritzing to get a bin’s path; it says that the absoluteFilePath() methos on windows always capitalize the drive letter; since Fritzing uses the QTString::compare(…) method with no case sensitivity parameter specified, the two paths it compares are different.

I take it something about the order of the calls does the necessary changing the case of the drive letter so the compare works? An alternative would perhaps be to use the toupper() or tolower() calls before the compare to make the strings all the same case, but that may have other undesirable outcomes. You can always make a pull request on github because if this fixes the problem even some of the time that would be an improvement I expect, but I still wonder why more of us haven’t seen it.

To do a pull request you fork the Fritzing app repo on Github. Then you create a branch called something like “drive_case_sensitivity” and commit the change to that branch of your fork. Then you can go to github and click the “new pull request” button while in the Fritzing repo and select your new branch and the main fritzing repo and explain why you are creating it.