Image “Capture5” shows a state which should not happen.
It is not obvious at all that the connection is not there.
Also, there shouldn’t be a ratsnest line next to the wire.
I assume this was Fritzing 0.9.9. Is this repeatable?
For me yes it is 0.9.9, as to repeatable, that I’m not sure of. I think this is an instance of a bug I have been chasing for about 5 years now where making a wiring error in another view corrupts the routing data base. The problem is (as in this case) is the examples I have are after the damage is done. Here the pins in schematic on the 7805 are backwards causing a short between ground and24V in schematic. I think that has corrupted the routing database somehow (from past examples) I deleted the wires in error like this
delay unit new4-base.fzz (42.9 KB)
Here there is no short between ground and 24V and the two wires are only rats nest lines.
In schematic these two rats nest lines with the red arrow between them were reversed causing the short between 24V and ground and I think causing the extra rats nest lines in breadboard.
the problem is changing schematic to match the original in delay unit new4.fzz doesn’t cause the extra rats nest lines to appear here I added wires to the two rats nest lines in breadboard
then reproduced the short in schematic
and extra rats nest lines in breadboard, but not across the two wires:
so this doesn’t recreate the incorrect rats nest lines between the wires. I believe there is some sequence of actions or order of making the connections that causes the problem, but from the results (both this one and 4 or 5 more from the past) I haven’t so far been able to figure out what that sequence is to reproduce this. I think the error is likely in the communication between schematic and breadboard via IPC when the change is made, but without the sequence of changes that cause the error it is pretty much impossible to debug. If @bob can remember the order of the sequence of connections he made, that may reproduce it, but I think that it is unlikely that he will remember this far along.
Peter
I am sorry Peter, I am afraid you are correct, I don’t have any recollection of the sequence.
I have now produced the board without the errors so I can happily leave it there.
I wonder if I was to ask someone to produce a board for me it would cause problems, though why I would want to ask someone to produce a veroboard for me as opposed to a printed circuit board I have no idea. 
Either way I now have a good representation of the board I am building that thanks to Fritzing looks a lot better than a hand drawn version.
Bob.
That is fairly common when this happens. It normally takes a while to recognize something has gone wrong and by then you don’t remember what you did.
Peter
Which Fritzing version are you using? I have been assuming 0.9.9 (which is the latest) but is that correct or are you on an earlier version?
Peter
Hi Peter,
I am using version 0.9.3 . I did talk earlier about updating and when I tried it said I would lose all the extra parts I had added.
I don’t have them cleanly stored so I am not sure where they all are or how to restore any it deletes so I am reluctant to update.
Bob.
Thanks, I opened a bug report on this on github to document it, even though we currently can’t reproduce it. So I’ll update that to indicate this is 0.9.3b not 0.9.9 as I assumed.
They should be preserved across an update, but to be sure you can copy the user directories to another file and restore them (while Fritzing is shut down) and Frtizing will start using them when it restarts.
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)
linux
~/Documents/Fritzing/parts
~/.config/Fritzing
Mac
/Users/username/Documents/Fritzing/parts
~/.config/Fritzing
Peter