Search function in the parts view does not work

What version are you running and what platform? I’m on 0.9.3 from about 6 months ago on win7 pro and don’t see either problem. As well my directories are in my documents (so that upgrades to the Fritzing directories don’t affect them). I’d be tempted to try a redownload and reinstall the code to see if you have a corrupted download although I haven’t heard any reports of that either.

Peter

v0.9.3b04.19 on W10 64bit. I had tried re-downloading. 0.9.2 works fine but I need the newer parts.

Just found this is logged as a bug in github:

A few people had this problem, unfortunately no one said if they found a solution.

When you unzip the fritzing.0.9.3b.64.pc - 186,786 KB file, does it have 128 folders 9049 files 343 MB.

Just wondering if your anti-virus is stripping files.

Thats a good thought, because something is sure wrong as the data files are in the wrong place. I have a disk with Win10 for my machine (from when upgrade from 7 was free :slight_smile: . I just don’t use it. I’ll restore a copy later today and try it against 9.3 and see what happens.As well new parts should still work on older versions, they are just somewhat of a pain to extract and load if we can’t find a fix.

Peter

Old_Grey, it is a bit different between the two versions (32 vs 64).
I downloaded the fritzing.0.9.3b.32.pc - 179 MB (187,819,731 bytes).
After unzipping it, size: 334 MB (351,095,049 bytes) that contains: 9,039 Files, 128 Folders.
I double check the end result with the zip file content and there was not a single problem.

I remembered it was a problem for some installing 9.3, so it was kind-of a guess.

Doing some reading it looks like something about a parts folder that triggers it. Directly manipulating external files can trigger it.

At the bottom of this post one of the FZ crew has a solution.
http://fritzing.org/forum/thread/6141/

Other reading
Near the bottom someone causes the problem

OK a new data point. I have an upgraded from Win7 pro copy of Win10 (which I don’t like and don’t use) which is probably at a patch level at least a year or more old. It didn’t ever have Fritzing on it, so I just installed the 64 bit zip file. Starting Fritzing I got the “we need to delete these files to do the parts update” which I approved, it then did the parts update and closed Fritzing. When I restarted fritzing and clicked the search hourglass and search comes up and works as expected. So search does work on Win10. I’ll leave the machine alone for a while (I have several :slight_smile: ) to do updates and see if an update kills it. Note Old_Grey’s post just before this that deleting the directories has worked for other people in the past although someone here tried that without success, I still think that is the most liekly cause of this. I may try loading a part that I know hangs fritzing and see if that breaks it as well a bit later as well if patches don’t break it (I can see traffic on my adsl modem probably indicating the other machine is loading patches :slight_smile: ).

Peter

I just did an install of Fritzing on Win10 and the directories are in the expected (mostly) place:

c:\Users\user_name\AppData\Roaming\Fritzing

and (slight change) (edit, slight wrong change, there is a user name
there too :slight_smile: ):

c:\Users\user_name\documemts\Fritzing

(where documents is My Documents on win7). so there is something odd about your installation I expect. As noted however search is also working for me (indicating it will work on Win10)

Peter

Is it really C:\Users\documents or C:\Users\username\documents?

Sorry, good catch, it is in fact c\Users\user_name\documents (although in typical Win10 fashion I had to start a dos prompt and do a dir as explorer claims it is “This PC> Documents” no user name in sight). It shouldn’t however be in the C:\Fritzing directory. On my working Win10 install its in C:\Users\Peter\Documents\Fritzing\bins\search.fzb and
c:\Fritzing contains only fritzing.0.9.3b.64.pc as that is where I unzipped the downloaded file. Are you using explorer to look for the files? If so perhaps try it from a command prompt in case you are hitting the same issue that bit me with explorer simplfying the path for us dummies … We may be in fact talking about the same directories. Also try starting Fritzing and under help click Enable debugging log, on mine that gets the single line

loading bin ‘Search’

when the working search window comes up. I’d be interested in what yours says when the window doesn’t come up. That may give us a clue as to what is going on. I’ll edit my other post to add the username to the path.

Peter

The fact that the search bin file is created under a different folder (C:\Fritzing\bins vs C:\Users\username\Documents\Fritzing\bins) seems significant.

I wonder if this is something to do with environment variables.

There seems to be 2 parts to this functionality:

  1. Search as a parts folder - same as any other
  2. A function that sits over the folder to facilitate search including provision of the search box. This bit seems broken.

How do you do the second one? The only one I know of is the search in parts bin. As far as I know (which isn’t all that far :slight_smile: ) all the user related changes are supposed to appear in the Fritzing\My Documents or Fritzing\Documents and Fritzing\Appdata directories (and their equivalent on the other platforms) so that no user related changes happen in the main distribution directories to be damaged during an upgrade (core parts do get changed in that directory when a parts update occurs on github but I think nothing user related is supposed to change there). In the movable parts discussion in parts help it appears a parts folder rename on the user’s part is what broke the search functionality. It was working on Win10 (just like mine), he made a part related folder change that made a folder inaccessable in Windows and Fritzing, and search has stopped working and hasn’t yet recovered (we so far haven’t convinced him to try and delete the user diirectories to see if that helps). To me that points to something getting corrupted in the two user directories that causes this, but not being able to reproduce it I can’t say for sure.

Peter

After upgrading Windows 10 to the Anniversary Update the search box is now working!

I wonder if something got repaired, or something that was missing got added.

My suspicion is that it was something to do with the HOMEDRIVE environment variable previously pointing to a network drive which whilst it exists, is never actually used. I had tried overriding this variable and re-installing Fritzing but it made no difference. Whenever the PC was rebooted it would be set back to the network drive. This is no longer happening after the update.

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

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:

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

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.

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

Peter