Search function in the parts view does not work


#43

Thanks for the update! I think we are probably seeing two different problems here, yours seems to have been something in Windows rather than in Fritzing and I’m pretty sure the other fellow (whose search failed after a part problem) is having the corrupted temp files problem (but so far doesn’t want to try and clear the temp directories). That at least gives us two suggestions to help people with this problem

Peter


#44

Can someone explain how to get the search bar working again?
I tried deleting the directories in /AppData and /Documents and replaced the main program folder with a freshly downloaded copy but I still have no search bar. :blush:


#45

If you scroll down the left menu in the parts window do you find an icon of a magnifying glass somewhere? I’ve seen a case where it wasn’t at the top of the screen as normal but the bottom (and needed to be dragged to the top). If that isn’t it are you running Win10? It appears that one of the patches (that sometimes seems to fail on Win10) breaks search for reasons unknown. I think there were instructions on how to fix up Windows update so patches work correctly (which seems to fix the issue, although I’ve never seen it even on my Win10 machines).

Peter


#46

Hehehe. Me so silly!
To think it has been here all the time just kills me! lol
Thanks Peter, It was down at the bottom! :smiley:
Kevin.


#47

Sorry, I should have though to mention this one sooner :slight_smile: at least we eventually found it …

Peter


#48

Hi All,

this is my first post here.
I’ve downloaded the 64 bit windows version, the latest available (0.9.3b). I’ve installed it on two computers, one has win 7, the other one has win 10 with latest updates.
On both PC’s I’ve got this issue: the Search bin appears, but with no field in it so I cannot actually search. The debugging info says “loading bin search”.
I’ve noticed that at every startup the program creates a new copy of the “Mine” and “Search” bins and places them at the bottom of the bin’s list, so I’ve ended up with dozens of copies of the two bins. Please note that only the bins in the program are duplicated: no new my_parts.fzb or search.fzb files are created.
It looks like that a part of the problem is that at the startup the program “thinks” that the two bins do not exist and recreates them (not the files, only the icons in the list).

Any ideas?

Many thanks,
Giovanni Romeo


#49

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.

Peter


#50

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.

Thanks,
Giovanni Romeo


#51

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.

Peter


#52

Hi,

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.

Thanks,
Giovanni Romeo


#53

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.

Peter


#54

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


#55

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


#56

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


#57

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…


#58

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!

Peter


#59

Hi,

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


#60

Take a look, if you can, at

http://doc.qt.io/qt-5/qfileinfo.html

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
#61

I forgot to check that you got Fritzing from

http://fritzing.org/download/

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.

Peter


#62

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