Create a FeaturePython object part II

App::FeaturePython vs. Part::FeaturePython
Up to this point, we've focused on the internal aspects of a Python class built around a FeaturePython object, specifically an object. We've created the object, defined some properties, and added a document-level event callback that allows our object to respond to a document recompute with the method.

We still don't have a box, but we can easily create one. First, add a new import to the top of the file:. Then in delete the  statement and add the following line:

These commands execute Python scripts that come with FreeCAD by default:
 * The method generates a new box Shape.
 * The enclosing call to adds the Shape to the document and makes it visible.

If you have FreeCAD open, reload the box module and create a new box object using (delete any existing box objects, just to keep things clean).

Notice how a box immediately appears on the screen. that's because the execute method is called immediately after the box is created, because we force the document to recompute at the end of



But there's a problem.

It should be pretty obvious. The box itself is represented by an entirely different object than our FeaturePython object. The reason is because creates a separate box object and adds it to the document. In fact, if you go to your FeaturePython object and change the dimensions, you'll see another box shape gets created and the old one is left in place. That's not good! Additionally, if you have the Report View open, you may notice an error stating "Recursive calling of recompute for document Unnamed". This has to do with using the Part.show method inside a FeaturePython object. We want to avoid doing that.

Tip

The problem is, we're relying on the methods, which only generate non-parametric Part::Feature objects (simple, dumb shapes), just as you'd get if you copied a parametric object using Part Simple Copy.

What we want, of course, is a parametric box object that resizes the existing box as we change it's properties. We could delete the previous Part::Feature object and regenerate it every time we change a property, but we still have two objects to manage - our custom FeaturePython object and the Part::Feature object it generates.

So how do we solve this problem?

First, we need to use the right type of object.

To this point we've been using objects. They're great, but they're not intended for use as geometry objects. Rather, they are better used as document objects which do not require a visual representation in the 3D view. So we need to use a object instead.

In, change the following line:

to read:

To finish making the changes we need, the following line in the method needs to be changed:

to:

Your code should look like this:



Now, save your changes and switch back to FreeCAD. Delete any existing objects, reload the box module, and create a new box object.

The results may seem a bit mixed. The icon in the treeview is different - it's a box, now. But there's no cube. And the icon is still gray!

What happened? Although we've properly created our box shape and assigned it to a object, before we can make it show up in our 3D view, we need to assign a ViewProvider.

Writing a ViewProvider
A View Provider is the component of an object which allows it to have visual representation in the GUI - specifically in the 3D view. FreeCAD uses an application structure known as 'model-view', which is designed to separate the data (the 'model') from it's visual representation (the 'view'). If you've spent any time working with FreeCAD in Python, you'll likely already be aware of this through the use of two core Python modules: FreeCAD and FreeCADGui (often aliased as 'App' and 'Gui' repectively).

Thus, our FeaturePython Box implementation also requires these elements. Thus far, we've focused purely on the 'model' portion, so now it's time to write the 'view'. Fortunately, most view implementations are simple and require little effort to write, at least to get started. Here's an example ViewProvider, borrowed and slightly modified from

Note in the code above, we also define an XMP icon for this object. Icon design is beyond the scope of this tutorial, but basic icon designs can be managed using open source tools like GIMP, Krita, and Inkscape. The getIcon method is optional, as well. If it is not provided, FreeCAD will provide a default icon.

Add the ViewProvider code at the end of and in the  method insert the following line above the  statement:

This instances the custom ViewProvider class and passes the FeaturePython's built-in ViewObject to it. The ViewObject won't do anything without our custom class implementation, so when the ViewProvider class initializes, it saves a reference to itself in the FeaturePython's ViewObject.Proxy attribute. This way, when FreeCAD needs to render our Box visually, it can find the ViewProvider class to do that.

Now, save the changes and return to FreeCAD. Import or reload the Box module and call. You should now see two things:
 * The icon for the box object has changed. This proves that our ViewProvider is working as expected.
 * More importantly, there is also a box in the 3D view. If you do not see it press the button.

Note what we did here that differs from the way it was implemented for App::FeaturePython above. In the method, we called the  macro and passed it the box properties as before. But rather than call on the resulting object (which created a new, separate box object), we simply assigned it to the  property of our Part::FeaturePython object instead.

You can even alter the box dimensions by changing the values in the FreeCAD property panel. Give it a try!

Trapping events
To this point, we haven't explicitly addressed event trapping. Nearly every method of a FeaturePython class serves as a callback accessible to the FeaturePython object (which gets access to our class instance through the attribute, if you recall).

Below is a list of the callbacks that may be implemented in the basic FeaturePython object:

In addition, there are two callbacks in the ViewProvider class that may occasionally prove useful:

It is not uncommon to encounter a situation where the Python callbacks are not being triggered as they should. Beginners in this area need to rest assured that the FeaturePython callback system is not fragile or broken. Invariably, when callbacks fail to run, it is because a reference is lost or undefined in the underlying code. If, however, callbacks appear to be breaking with no explanation, providing object / proxy references in the callback (as noted in the first table above) may alleviate these problems. Until you are comfortable with the callback system, it may be useful to add print statements in each callback to print messages to the console as a diagnostic during development.