Including imported parts with the *.fzz-file itself for easier dataexchange

Hi everybody,

I’m on a project with a friend.where sometimes me and other times my friend is working on the same file. For easiest dataexchange it would be good if there would be a possability to include all imported parts or even really all parts that are used in the file would be included inside the *-fzz-file.

Without this it is always a hassle to import new files and to store them at the exact same place so the software of the other person will find it.

From IronCAD I’m used to that it just has all parts included in one single file.

best regards Stefan

That will probably never happen because people make parts and host them themselves without telling anyone. Basically parts aren’t submitted to one place. This is why you have to do a FZ forum and Google search for the part before you do anything.

Hi Old_grey,

thank you for answering.

So if you ever would start a collaboration with someone
and you would start adding additional parts found by google or self-created.

How would you organize the process of synchronising the *.fzz-file which is changed sometimes by person A some other times by person B?

best regards Stefan

Fritzing automatically includes all parts that are not part of the core (on the creating system) in each fzz file. There is no need to synchronize the locally imported parts before viewing an fzz file that someone else created.

An fzz file is really a zip file that wraps an fz (the actual sketch document) plus the files for non-core parts (part definitions and svg). The only place that extra synchronization is needed, is where the core parts library used by the sender and receiver are different. Making sure that is the same covers most of the use cases.

A custom part in an opened fritizing document can be exported, and and saved to a fzpz file locally. Each document (with custom parts) has a “temp” bin associated with, that includes those parts. So it is not even necessary to share parts that the other person wants to use them selves in other documents. They can be extracted from a shared document.

The only place this is likely to break down, is if custom (or modified) parts are being put directly into the core folders used by Fritzing. Since those are in “core” they will not be included in the fritzing document, or the temp bin for it. But anything that was initially imported from an fzpz part file should be included in an fzz documents that use it.

I have saved a *.fzz file and sended it by email to my friend. As he tried opened the file he got errormessages

The following part was not found…

see uploaded picture.

So I guess I must have done something wrong with fritzing
I downloaded the ZIP-file unzipped the file as a subfolder of my download-folder and just started fritzing.exe

Do I have to unzip it to a certain folder?
do I have to set a certain-path-variable?
best question of all: why is there no setup-exe like all other softwares have one with a installation-wizard that does all the rquiered adjustements to make the software run flawlessly?

best regards Stefan

The path in that error message points to a part that was imported. It should have been included in fzz file. Sometimes a error message like that is shown, but simply clicking “OK” continues and works. The saved (and emailed) fritzing document contains a reference to where the part file came from on the original machine, which does not exist on the machine that opened it. However, Frtizing is supposed to figure that out, and use the part included in the sketch file. But can first complain that it did not find the part where it was initially told to look.

Your description of installing Fritzing looks correct. No specific target folders or paths should be needed. I assume that is on a Windows machine, since you mention setup-exe. I use linux. There, there are some extra things that can be done to improve usage a bit, but are not needed to get it to run.

For setup.exe, the team that created Fritzing did not prioritize ease of install, and the current group that works with the code have limited resources. I think higher priority should be put on simplifying install and first run, but I don’t make those decisions.

Hello Micromerlin,

thank you very much for answering. After a second opening the problem remains. There is shown the error-message and the part isn’t shown in the file.

Does Fritzing have some kind of debug-logfile which might give hints what is going wrong?

What would you recommend to do ? Should I try to install it under
C:\Users\Stefan\Documents\Fritzing to have all things in one place?

Could I just unzip the zipfile to another subfolder? Or should I delete everything related to Fritzing first?

Could this be a problem of the BitDefender-Total-Security-Suite trying to protect some folders from unauthorised filewriting?

Can I adjust the default-folders to other locations? And if yes where can I adjust them?

best regards Stefan.

I haven’t seen a .fz before so I don’t know how he got it, but someone posted a .fz sketch file here and that has missing parts. Are you sending the .fzz file.

@Old_Grey You get a .fz file (and more) by unzipping a .fzz file. It is the uncompressed sketch file. The “and more” would be the part files (fzp and svg) that belong with the sketch that are not part of core. So if someone unziped a .fzz (or just saved in uncompressed mode), then posted the .fz, the (non-core) part files would all be missing.

@StefanL38 Is the content of the problem fzz private? Can you post it here? (7th button from the left when editing a post or comment) With the actual sketch file, I can unpack it manually, to see what it contains, and what it tries to reference. The description so far says that for some reason Fritzing did not include that part in the sketch file. Do not put the fritzing program folder in Documents/Fritzing. That is intended to be the user data area. Putting the code there could end up mixing the core parts and user parts. The symptoms described do NOT sound like an installation problem. It could be a bug in the program that your specific sketch triggers. If you can upload both the sketch document, and the fzpz for the part that is missing when your friend opens it, I can look at both what parts are currently in the sketch, and try to recreate it, and check again if the part gets included.

It could be a problem with the part file itself. The fzpz files are created by various people, with varying quality. Some look OK, but are broken in different ways. I have some tools to check that too, if you can post the part file. Maybe the part file is good enough to open and use, but broken in a way that Fritzing can not save it in the .fzz file. But works for you, since it is found in the folder mentioned in that error message. Speculation. I need the files to try to verify.

Ahh now I see it, it’s a file inside the .fzz. I don’t really see why someone is doing the extra work to unzip a .fzz for a sketch that doesn’t work properly anymore.

A “good” fzz that is unzipped will continue to work, if it is still in the folder with the other files unzipped from the fzz. Unzipping a broken fzz can show what the problem actually is. The .fz file is xml, and can be read with a text editor, to match the part file references with what was actually unzipped. I have also unzipped an fzz to repair a problem with z ordering. I have had files where move to front/back stopped working, because somehow several parts ended up at the same (min or max) z level. Manually changing the geometry z entries to unique values fixes it, and gets the z ordering commands to work again. Its a bug, but I can work around it.

This occurs now. Any part that is not in the current core parts is automatically included in the .fzz file for the sketch and loads in to the temp parts bin. There is a bug that if the part already exists in the mine parts bin as well as the temp parts bin, instead of an error message, Fritzing will use the part from the mine parts bin if I recall correctly. Since the core parts are updated automatically from the master github repository, the core parts should always be the same (they won’t be in the case where github can’t be accessed, for instance if you don’t have network access which can cause problems.)