How do I highlight a failing edge with opFillet like the native fillet feature?

EvanReese

When using the fillet feature, it highlights at least one problematic edge when the feature fails. How do get this behavior from a custom feature calling opFillet?

I've dug around the Standard Library Source looking for how it's done, but to be honest, I don't understand how it is all interconnected. Can someone point me in the right direction?

NeilCooke

I'm wrong again (I'm just flailing around in the dark here, literally) - it is the feature id - if the feature uses the top-level id of the custom feature then it works so:

        opFillet(context, id, {
                    "entities" : finalQuery,
                    "radius" : definition.radius
                });

works, but

        opFillet(context, id + "fillet1", {
                    "entities" : finalQuery,
                    "radius" : definition.radius
                });

does not. So as long as the result of your feature is this one opFillet, then you can use the top-level id. If not, who knows.

Interestingly, setErrorEntities also only seems to work with the top-level id.

Jake_Rosenfeld

@Evan_Reese

@NeilCooke asked me to shed some light on this.  Basically, error entities are attached to an id.  If you want error entities to show up, they have to be attached to the top-level feature id.  We do not automatically migrate subfeature/suboperation error entities to the top level feature because that is not always the desired outcome.  Imagine, for instance, calling a Boolean operation in your feature, and, if it fails, catching that failure and instead trying to do that boolean in smaller batches (this is how fix pcb works).  You would not want the error entities from the initial boolean to come through, because that did not cause a feature failure.

The appropriate way to bootstrap error entities from a subfeature to the feature itself is as follows:

try
{
    opFillet(context, subId, ...);
}
catch (error)
{
    processSubfeatureStatus(context, topLevelId, { "subfeatureId" : subId, "propagateErrorDisplay" : true });
    throw error;
}

Or to just pass the top level id directly into the fillet (but, this can only be done for one subfeature, since ids passed into subfeatures must be unique)

To get the nice code box you can click on this button:

and then paste the code from your feature studio into the empty box that shows up.

john_mcclary

Isn't that usually done with debug()     ? 

EvanReese

yes, and I know how to use debug, but I don't know how to identify which edge to highlight. There's not an instance of debug called in the Fillet code. That makes me think it's somewhere in the imports at the top. I found std | error.fs  but I'm still not sure if it's what I'm looking for, and if so, how to use it.

NeilCooke

Finding the edges that error is all done server-side. If you want to do it in code you would probably have to loop through each edge and find which ones fail (which would be horribly slow).

NeilCooke

Actually, I stand corrected - opFillet is looking for definition.entities - if the entity selection is called anything else, it won't show the errors.

jakeramsley

Hi Evan_Reese,

Please take a look at the documentation for setErrorEntities (https://cad.onshape.com/FsDoc/library.html#setErrorEntities-Context-Id-map).  

EvanReese

NeilCooke said:

Actually, I stand corrected - opFillet is looking for definition.entities - if the entity selection is called anything else, it won't show the errors.

Interesting. So if I used definition.entities then opFillet would highlight failing edges automatically? For my feature, I'm combining a lot of different optional queries to reach the query of final entities so I don't think I have that option. Here's what that part of my code looks like:

        var finalQuery = qSubtraction(runningQuery, exclusions);

        {

            opFillet(context, id + "fillet1", {

                        "entities" : finalQuery,

                        "radius" : definition.radius,

                        "tangentPropagation" : definition.tangentPropagation

                    });

        }

Any idea how I can still get errors to show?

(how do I format the code better?)

@jakeramsley
that sounds like what I need, but I'm too novice to know what to do with it just based on the link you sent.

NeilCooke

I'm wrong again (I'm just flailing around in the dark here, literally) - it is the feature id - if the feature uses the top-level id of the custom feature then it works so:

        opFillet(context, id, {
                    "entities" : finalQuery,
                    "radius" : definition.radius
                });

works, but

        opFillet(context, id + "fillet1", {
                    "entities" : finalQuery,
                    "radius" : definition.radius
                });

does not. So as long as the result of your feature is this one opFillet, then you can use the top-level id. If not, who knows.

Interestingly, setErrorEntities also only seems to work with the top-level id.

EvanReese

@NeilCooke
That did the trick! Thanks!

I'm not sure what I've learned here other than "ask the forums next time I'm stuck." If someone who knows how this works feels like writing any kind of explanation, long or short, I promise to read it and try to understand. Otherwise, I'll just be on my way to get this feature ready enough to share.

Jake_Rosenfeld

@Evan_Reese

@NeilCooke asked me to shed some light on this.  Basically, error entities are attached to an id.  If you want error entities to show up, they have to be attached to the top-level feature id.  We do not automatically migrate subfeature/suboperation error entities to the top level feature because that is not always the desired outcome.  Imagine, for instance, calling a Boolean operation in your feature, and, if it fails, catching that failure and instead trying to do that boolean in smaller batches (this is how fix pcb works).  You would not want the error entities from the initial boolean to come through, because that did not cause a feature failure.

The appropriate way to bootstrap error entities from a subfeature to the feature itself is as follows:

try
{
    opFillet(context, subId, ...);
}
catch (error)
{
    processSubfeatureStatus(context, topLevelId, { "subfeatureId" : subId, "propagateErrorDisplay" : true });
    throw error;
}

Or to just pass the top level id directly into the fillet (but, this can only be done for one subfeature, since ids passed into subfeatures must be unique)

To get the nice code box you can click on this button:

and then paste the code from your feature studio into the empty box that shows up.

EvanReese

Jake_Rosenfeld said:

@Evan_Reese

@NeilCooke asked me to shed some light on this.  Basically, error entities are attached to an id.  If you want error entities to show up, they have to be attached to the top-level feature id.  We do not automatically migrate subfeature/suboperation error entities to the top level feature because that is not always the desired outcome.  Imagine, for instance, calling a Boolean operation in your feature, and, if it fails, catching that failure and instead trying to do that boolean in smaller batches (this is how fix pcb works).  You would not want the error entities from the initial boolean to come through, because that did not cause a feature failure.

The appropriate way to bootstrap error entities from a subfeature to the feature itself is as follows:

try
{
    opFillet(context, subId, ...);
}
catch (error)
{
    processSubfeatureStatus(context, topLevelId, { "subfeatureId" : subId, "propagateErrorDisplay" : true });
    throw error;
}

Or to just pass the top level id directly into the fillet (but, this can only be done for one subfeature, since ids passed into subfeatures must be unique)

To get the nice code box you can click on this button:

and then paste the code from your feature studio into the empty box that shows up.

Thanks, Jake, that made sense! I really appreciate it.

mahir

Jake_Rosenfeld said:

To get the nice code box you can click on this button:

and then paste the code from your feature studio into the empty box that shows up.

On a mostly unrelated note, I didn't use the Code formatting option for a long time because I didn't think it worked. At least for me, the preview just looks like a yellow box with a monospace font applied to the text. I only recently realized that the proper formatting and color coding doesn't get applied until the comment is posted.

EvanReese

@mahir yep that was part of my problem. Also when I posted it it looked like it just ran off the right side of the screen, maybe I should have just left it

NeilCooke

The trick is to make sure you press the code formatting button BEFORE you paste the code.