Overriding 'Expected Query' when running an imported feature within another

Jonathan_Hutchinson

I've had a little dabble with importing and running a feature from a different document within another feature's body. What I'm experiencing though is that where the imported function expected queries for vertices etc, I would like to be able to pass in vertices which have, for instance, been calculated/determined in a way that isn't just related to clicked query parameters.

Does that make sense? The bind I'm seeing is that it appears I need to go backwards from a Vertex, to a query (which in this case isn't possible given it's not a vertex that belongs to an entity). My workaround at the moment is to instantiate the thing I calculate so it is an entity, a vertex in this case via opPoint, feed that into the query, and delete it afterwards. Just hunting to see if I'm missing a trick somewhere in the original defining function.

Evan_Reese

I don't totally follow here, but I'd do something similar if I needed a query for something like a point or a plane and only had the vectors.

chadstoltzfus

I've done this before, especially for things like opEnclose, which requires planes as queries. So you'll see something like this whenever I try to use that function

// Creates planes to use for making an enclosure
        opPlane(context, id + "leftPlane", {
                    "plane" : leftFace
                });
        opPlane(context, id + "rightPlane", {
                    "plane" : evPlane(context, { "face" : definition.rightReturn })
                });
        opPlane(context, id + "bottomPlane", {
                    "plane" : bottomFace
                });
        opPlane(context, id + "topPlane", {
                    "plane" : evPlane(context, { "face" : definition.topFloor })
                });
        opPlane(context, id + "backPlane", {
                    "plane" : evPlane(context, { "face" : definition.backFace })
                });
        opPlane(context, id + "frontPlane", {
                    "plane" : evPlane(context, { "face" : definition.frontFace })
                });

        var planes = qUnion([qCreatedBy(id + "leftPlane", EntityType.FACE), qCreatedBy(id + "rightPlane", EntityType.FACE), qCreatedBy(id + "bottomPlane", EntityType.FACE), qCreatedBy(id + "topPlane", EntityType.FACE), qCreatedBy(id + "backPlane", EntityType.FACE), qCreatedBy(id + "frontPlane", EntityType.FACE)]);

        opEnclose(context, id + "enclose", {
                    "entities" : planes
                });

Evan_Reese

oh oh oh! Thread hijack alert, but Chad, I recently learned more about IDs and I think you could set these up in a way that makes your query easier and more update-able. I haven't tested this, but I think this (or something similar) should also work. 

        opPlane(context, id + "plane" + "left", {
                    "plane" : leftFace
                });
        opPlane(context, id + "plane" + "right", {
                    "plane" : evPlane(context, { "face" : definition.rightReturn })
                });
        opPlane(context, id + "plane" + "bottom", {
                    "plane" : bottomFace
                });
        opPlane(context, id + "plane" + "top", {
                    "plane" : evPlane(context, { "face" : definition.topFloor })
                });
        opPlane(context, id + "plane" + "back", {
                    "plane" : evPlane(context, { "face" : definition.backFace })
                });
        opPlane(context, id + "plane" + "front", {
                    "plane" : evPlane(context, { "face" : definition.frontFace })
                });

        var planes = qCreatedBy(id + "plane", EntityType.FACE);

        opEnclose(context, id + "enclose", {
                    "entities" : planes
                });

chadstoltzfus

Oh yeah this is older code of mine. I've been messing around with ANY_ID lately and have found some good uses for it, especially in for loops. I didn't know you don't need the ANY_ID if you concatenate a second string through, very slick! 

Evan_Reese

I've not used ANY_ID before. I'll give it a go!

NeilCooke

Remember that id is an array, not a string. ANY_ID ( = "*" ) is useful if the middle id array element is variable, such as id + ANY_ID + "plane"

Evan_Reese

Thanks, Neil. I'll take any FS education you're willing to dish out!

Evan_Reese

Evan_Reese said:

I've not used ANY_ID before. I'll give it a go!

I should correct this, actually. I did use it in the Grid Extrude feature, but at someone smarter's suggestion, so I don't feel like I've used it, haha.