Search function in the parts view does not work


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.



Hi Peter and thanks.

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” :slight_smile: Unfortunately this process is not very straightforward, I can compile the software inside QTCreator, but the program crashes at startup…

We’ll see.

Giovanni Romeo


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 :slight_smile: ) 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.

Giovanni Romeo


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.



I’ve noticed that build instructions says:

Windows: select 5.6 > MinGW or msvcXX OpenGL (either 32bit or 64bit depending on your machine)

but msvcXX OpenGL is available only up to QT 5.4… No msvc OpenGL starting from 5.5 …

Giovanni Romeo


Great news, I’m able to compile and run it! :grinning:


Hi all,

I’ve resolved the issue!!! It’s a “case sensitivity” problem.

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.

Now I want to find an elegant way to solve the bug.

Many thanks,
Giovanni Romeo


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.

Giovanni Romeo


Take a look, if you can, at

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 don’t understand why other people are not having the issue :slight_smile:

Giovanni Romeo

Run inside QTCreator

I forgot to check that you got Fritzing from

which is the official release site (and where I got mine). If you got it from somewhere else that may be the issue (not that I know it is available from anywhere else, but it may be).

On my working Win7 machine (I have the files redirected off the system partition which is why the f:) the bins show as

F:\Fritzing\My Documents\fritzing\bins\my_parts.fzb
F:\Fritzing\My Documents\fritzing\bins\search.fzb

both file names all lower case and the drive letter upper case (at least in explorer) are what it is using.



Could your problem have to do with Language settings in Windows?


I’ll check that too.
For the next few days I won’t be able to work in this since it’s almost Christmas and, you know, I have other things to do :wink:

Merry Christmas!



Hi all and happy new year.

Finally I’ve tracked down (is that correct english :sweat: ?) the issue, I think it could be merged into git.
first of all take a look at the following (closed) QT issue

even if the issue has been closed, you can clearly see that in some cases under windows there can be inconsistencies is the drive name to be upper/lowercase.

To “happily” solve the issue I’ve changed a coupèle of lines in folderutils.cpp from:

QString FolderUtils::getUserBinsPath() {
    QDir dir(getTopLevelDocumentsPath());
    return dir.absoluteFilePath("bins");


QString FolderUtils::getUserBinsPath() {
    QDir dir(getTopLevelDocumentsPath() + "/bins");
    return QFileInfo(dir, "").absoluteFilePath();

and it works!

Let me know if you agree and how to proceed.

Many thanks,
Giovanni Romeo


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.




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

yes, I’ve tried that, but strange things happened :smile:
The (most probable) reason why most people did not see the issue is perhaps the way the OS is configured or the way the application in installed/started (

Regarding the pull request, I cannot do it, I cannot even do a git push since I have no permission to do that. Do you know who can I ask to to be granted the permission to push?

Many thanks,


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.