Extended part (fzp) properties


I’m creating a component (ex: a resistor) for which I need to set its value (ex: 100 ohm) or to choose it in a list.

I looked at other parts but I didn’t found how to. So I read fritzing app code which create the property panel and discover interesting options which doesn’t work in my versions. Does someone know in which version they works ? @KjellM ?

Here is an example of these very promising features:

<property showInLabel="yes" numeric="yes" editable="yes" defaultValue="10" minValue="1" maxValue="1000" symbol="ø" name="resistance">
			<suffix suffix="">A</suffix>
			<suffix suffix="">B</suffix>
			<menuItem value="V1"></menuItem>
			<menuItem value="V2"></menuItem>
			<menuItem value="V3" adjunct="ABC"></menuItem>
			<menuItem value="V4" adjunct="DEF"></menuItem>

I tried to build the app to check or debug and see where I’m wrong, but I got stuck during link phase… no surprise here I migrated the build to cmake and CLion (more use to these tools) and I certainly missed some options.


In general (and in the case of resistors) there is special code (triggered from the family name resistor) that provides those services. It is possible (if undocumented) to set the family of your part to resistor and edit the .fzp file to have the correct settings in the properties section to use those features. There are a number of other similar parts (generic IC, generic connectors, the mystery part, breadboards and probably others I’m not remembering.) as well.


I guess that you found the resources/properties.xml file. There you can specify if a field is editable (and other properties of the field). The only problem is that it will only work if the part is based on the Capacitor class.
You can check the src/items/partfactory.cpp code, which defines if a part is create based on the capacitor (or resistor class), where you can change properties, or as normal part without that functionality. I think I modified the code to automatically create capacitor classes if the suffix matches the module id of the part.

In any case, I think you will have to compile your own binary to make it work.

Great !

Thanks, I tested the resistor case and finally looked at the code. Something changed, now we need to have the moduleId ending with ResistorModuleID.
I also added a property named Resistance (may need to confirm if capital R is necessary or not), but it requires to have a value. Otherwise the dropbox is not displayed.

There is something strange to me. Reading the code, if we use a suffix from properties.xml, like ZenerDiodeModuleID it drives the factory to choose a Capacitor instance. I haven’t done a test yet…

Thanks you all, that helps a lot.

Capacitor class is a class that allows to change properties of a device, it does not mean that the device is a capacitor.
The resistor class extends the capacitor class to have the code for the colour band of the resistor.
I agree that the names of the classes are not very intuitive…

The last time I did something with the resistor family was 3 or 4 years ago on 0.9.3b so the ResistorModuleID may indeed be a new addition. There are a couple more cases I know of with moduleIds with prefixes or suffixes and with development running again things are changing (for the better!)


I wonder if this is another case where the Fritzing version specified in the part is important. That has been used in earlier versions to change the way Fritzing handled certain situations.