I was just testing a new part that I’d made, when Fritzing crashed. Everything seemed fine with the part, but after some time, I wheeled the mouse and the program crashed.
Trying to reload the part I get the message “There is already a part with id …”
If I do a parts search, it finds my part. I’m not sure where, but I can drag it and use it normally. If I right click it the “remove part” is greyed out.
I’ve tried to “regenerate parts database”, I get this error.
Edit.
I’ve back-tracked and worked out what caused the initial crash. I put the part family as 40xx (which it is), but this allows you to change the number of pins (for some reason). While I was scrolling down the inspector and it picked up the pin number drop down menu (unintentionally) and changed it to 16 pins. This crashes fritzing very reliably every time!
I’m guessing this problem is because my part has sub-parts.
The problem remains; that I can’t regenerate parts database without it crashing.
There are problems with the mouse wheel being able to overrun Fritzing’s response time (usually you get a second part in the sketch.) The solution is likely to be disabling the mouse wheel for some set of selections, as this isn’t easy to fix. When Fritizing crashes with a bad part usually the parts database gets corrupted. The easy fix is this:
There are two user directories (with your parts and the parts database) which don’t get touched during an install (to not affect your sketches during upgrades). On Windows they are in
c:\users\username\AppData\Fritzing\roaming\Fritzing (which is a hidden directory so you need to enable hidden directories in explorer) and
c:\Users\username\My Documents\Fritzing (where username is your windows id)
If you don’t have any parts or sketches you want to keep you can just delete those two directories and Fritzing will recreate them, or you can move them aside by renaming them if you want to keep something in them.
However as noted that wipes out all your saved parts in the mine parts bin. I keep all my custom parts as .fzpz files and usually wipe the user directories and reload the mine parts bin from the fzpz files. If you don’t want to do that it is possible to remove the files for the individual part from your documents\Fritzing directory like this:
then for safety delete all the svg files in the svg directories (only breadboard shown here.) although I think only the .fzp file will cause the “is already a part” error.
That usually indicates the .fzp file exists in the mine parts bin, but has been lost in the database and removing it should fix it.
You need to change the permissions on the fritzing-parts directory to give full control to the user you are running as in order to change (or do automatic updates) on the parts. I apparently hadn’t done that when I installed 0.9.8 so I got the same message until I did this:
There is a family of subpart parts with a family like 40xx (from Steve Perry) in core parts. You may have picked the same family name in which case your new part will be swapable with the current 40x parts in Inspector (the 4070 is one I remember, there are 8 or 10 as I recall.) I prefer to give each part (unless it is the same part in a different package) a unique family name so the swapping mechanism won’t try and swap it.
With trial and error after a sleep, I’ve found that you can drag the hidden part from the search results into My Parts. Once it is in there then it can be removed normally (remove part is greyed out in Search). Save library, reload Fritzing and everything is back to normal again.
I’ve changed the permissions on the fritzing-parts directory to give full control and now I don’t need to run as administrator, but it still crashes Fritzing every time. It starts to regenerate parts database for a few seconds, then the whole program disappears, no warnings, nothing, just vanishes.
I don’t understand what “regenerate parts database” is supposed to do. I thought it would help with my parts error, but I solved that problem (thanks to Peter) by changing the family property of my part and the broken part clean up above.
I can continue using Fritzing now, but I’m curious why the “regenerate parts” doesn’t work.
This is normal operation. When the database is regenerated at the end it shuts Fritzing down to commit the database. On restart the reqenerated database is used.
