Gotcha! qCapEntity returns no START cap unless extrusion was orthogonal to the world

blackslate

To see a demo of this issue, please visit my Extrude Cap Test document and double-click on the Extrude Cap Test feature to open the dialog and show debug feedback.

In Debug Mode, you should see a red plane and a green face. The face is the result of the query of the type: qCapEntity(extrudeId, CapType.START, EntityType.FACE). All well and good.

However, if you deselect either "Sketch on world plane" or "Extrude along world axis", the green debug feedback will disappear. In the FeatureScript notices, you will see:

capFace START debug: Query resolves to nothing

If you choose to show the END cap in the dialog, you will see two green debug faces,  the notice "capFace END debug: Query resolves to 2 faces".

I expected to see one START cap face and one END cap face for every extrude, regardless of the plane on which the sketch is drawn and the extrusion direction. Have I misunderstood something?

NeilCooke

Yep, looks like a bug.

NeilCooke

Yep, looks like a bug.

NeilCooke

As an interim workaround, you could:

        if (definition.capType == CAP_TYPE.START)
        {
            capFace = qCapEntity(extrudeId, CapType.START, EntityType.FACE);
            
            if(isQueryEmpty(context, capFace))
            {
                capFace = qCoincidesWithPlane(qCapEntity(extrudeId, CapType.END, EntityType.FACE), sketchPlane);
            }
        } 

blackslate

Thanks for your confirmation that this is not pilot error, Neil!

I've updated my Extrude Cap Test document, and now you can:

1. Reproduce the bug with all EntityType's

2. Choose to use an overloaded version of qCapEntity(), which (I believe) fixes the bug, and which should simply fall back to using the built-in version of qCapEntity() when this bug gets fixed.

I have two related questions about good practice:

1. I overloaded qCapEntity() with a new signature. For scripts which might be used by other FeatureScript writers, is this good practice?

2. I wrote a function called qyDoesntCoincideWithPlane(), where I deliberately use "qy" so that it is clear that this is not a built-in function. Is this also good practice?

NeilCooke

There are no standards set, but it's probably best to avoid overloading built-ins. Your parameters are different so you would have to edit your code when it gets fixed anyway, so probably best to give the function a unique name also.