Why does this editing Logic query not work

dave_cowden

I have a feature that accepts both an edge and a face.  My goal is to use an editing logic function to pre-populate the face that contains the provide edge, if there is one.

In the example below, you can see that the editing logic does select a face. But then there is an error assigning it to the definition: "Editing logic result Parameter "face" does not satisfy spec. But it should, because it is clearly a query.

What am I missing?




Complete code:

FeatureScript 370;

import(path : "onshape/std/geometry.fs", version : "370.0");

annotation { "Feature Type Name" : "My Feature", "Editing Logic Function" : "editLogic" }

export const myFeature = defineFeature(function(context is Context, id is Id, definition is map)

    precondition

    {        

        annotation { "Name" : "EDGE","Filter" : EntityType.EDGE }

        definition.edge is Query; 

                        

        annotation { "Name" : "Surface","Filter" : EntityType.FACE }

        definition.face is Query;         

    }

    {

        debug(context,definition.face);    

    });

//You can also add a boolean argument to the cPlaneLogic function as the last argument 

//(this is currently undocumented but it makes the logic function run when the feature is edited, not just created).

export function editLogic(context is Context, id is Id, oldDefinition is map, definition is map,

                              isCreating is boolean, specifiedParameters is map, hiddenBodies is Query) returns map {

    

    if (oldDefinition == {} ){

        var pnt = evEdgeTangentLine(context, {

                "edge" : definition.edge,

                "parameter" : 0

        });

        

        var p = qNthElement(qContainsPoint(qEverything(EntityType.FACE),pnt.origin),1);

        debug(context,p);

        definition.face = p;

            

    }

    return definition;

    

}

kevin_o_toole_1

You may actually need to do:

qUnion(evaulateQuery(context, p))

We generally keep query input values as individual, evaluated queries, to make it easy to display them to a user as a list with names like "edge of ___", each with an x to delete it.

This behavior definitely needs better documenting (and possibly a better error). Sorry for that on both accounts!

ilya_baran

This is a bug -- it's not fixed in the next update, but once the one after the next update ships, a feature using the latest FS will be able to do definition.face = p;, like you originally wanted without the qUnion(evaluate...) workaround.

john_f_carr

Just looking at our server code and not trying your code, you need to return a qUnion() result even if there is only one thing in the query.

kevin_o_toole_1

You may actually need to do:

qUnion(evaulateQuery(context, p))

We generally keep query input values as individual, evaluated queries, to make it easy to display them to a user as a list with names like "edge of ___", each with an x to delete it.

This behavior definitely needs better documenting (and possibly a better error). Sorry for that on both accounts!

dave_cowden

Thanks guys, that works. Never would have guessed, thanks for the help!  

dave_cowden

For those who read this in the future, I had tried something similar, which also didn't work:

qUnion([evaluateQuery(context, p)])

Note in the above case the array syntax, which is the syntax most commonly used with qUnion.
If you use the array version, you
will get the same assignment error as above. In this case, you need to use the form without the array syntax, which I would never guess.

kevin_o_toole_1

Yeah, that makes sense. The tricky thing is that evaluateQuery() returns an array, so that qUnion would be constructed with an array of arrays, rather than an array of Queries.

ilya_baran

This is a bug -- it's not fixed in the next update, but once the one after the next update ships, a feature using the latest FS will be able to do definition.face = p;, like you originally wanted without the qUnion(evaluate...) workaround.

dave_cowden

alright, thanks!