Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Options

Passing in featureList as Argument, but not from a Feature Parameter

Jonathan_HutchinsonJonathan_Hutchinson Member Posts: 66 PRO
edited August 2023 in FeatureScript
I'm in a slight dead end figuring out how a feature I've written can be used by some other features, when the feature has an 'is featureList' input (to ingest all the things created by a feature, which may vary).

See the below example, where I want the thing represented by 'fList' to be a featureList type, and for it to contain the things created by id + "patternDivided". I don't quite understand how to pass something to the featureList function that will yield something of type feature list, and so get a precondition fail of 'is featureList'. I suspect, though, that I'm maybe abusing the featureList type here.
        opPattern(context, id + "patternDivided", {
                    "entities" : qCreatedBy(id + "divideEntities", EntityType.BODY),
                    "transforms" : transforms,
                    "instanceNames" : instanceNames
                });

        var fList;
        fToCall(context, id, { "feat" : fList });<br>
Tagged:

Comments

  • Options
    Alex_KempenAlex_Kempen Member Posts: 244 EDU
    edited August 2023
    The FeatureScript std has many functions which are intended primarily to be internal-only functions. As a result, these functions often have little to no documentation. In cases like that, it's best to check the source code directly. Here's the source for featureList:
    https://cad.onshape.com/documents/12312312345abcabcabcdeff/w/a855e4161c814f2e9ab3698a/e/532a337c28a6fe5a6eacd744

    Looking at the code, a FeatureList type is simply a mapping of ids to functions. From applyPattern, it appears that these functions take a single argument, an id, and execute the corresponding feature. The ids are the featureIds of a given feature in the list. The valuesSortedById function sorts the map into an array of functions as determined by the order of ids in the feature list, which makes sense since maps have an arbitrary internal ordering (usually alphabetical), and you logically need the feature list to be in order so they execute properly.

    Based on the above, it appears that the featureList type is not generally suitable for use in FeatureScripts outside of a FeatureList parameter. To my knowledge, there is no way to access other feature functions in the feature tree from another FeatureScript (short of using a FeatureList parameter, of course), nor is there any way to generate them at runtime, since a feature really needs a definition specified in the feature tree to be useful.

    As an alternative, I would recommend writing a lower level function inside fToCall which takes a query instead of a feature list (If you're into software design, this is a good example of dependency injection). This implementation is very similar to how Onshape is designed with high level functions (features) as well as the low level operations for said features (the op functions) - although you could call the high level functions directly, it's oftentimes much easier to call the low level operations directly.

    If you were to implement this, your fToCall function could become a trivial wrapper which converts the FeatureList into a qUnion of qCreatedBy calls before calling the inner function. I don't believe you were actually calling the features anyways, so you shouldn't have issues with no longer being able to tweak the behavior of each function before you execute them. Because of this, you also shouldn't have to worry about order, but if it was relevant then you could always take advantage of valuesSortedById to get a list of ids in evaluation order (you could remap your FeatureList to a mapping of ids to qCreatedBy calls, for example).

    Hopefully some of that makes sense - let me know if you want any additional clarification.
    CS Student at UT Dallas
    Alex.Kempen@utdallas.edu
    Check out my FeatureScripts here:



Sign In or Register to comment.