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

Feature Script simple question

jelte_steur814jelte_steur814 Member Posts: 78 PRO
Hi,

I'm learning Feature Script these weeks but i'm a newb to programming.
one of the custom features i created selects and edge (by user), and then the edgelenght is evaluated and used in many places.

it seems that the definition of the edge or a value created in the 'precondition' is available for all function calls below.
but I can't evaluate edgelength in the 'precondition' i believe. 
but when I evaluate the edge length in the first (main) function below it and put it in a constant, it's not available for other functions that are called separately.

How does this work? I'm trying to understand the basic programming principles here. it seems the constants are available in the level of { } they're created in, but preconditions are available more widely it seems.

I'm working on the optimization for this one: 
https://cad.onshape.com/documents/df7470bfcac6dbf738846c11/w/4e60241b9fc0b28698901775/e/27dcebec77fdc3f92e51e357

kind regards

Jelte

Comments

  • Options
    Konst_ShKonst_Sh Member Posts: 42 PRO
    edited March 20
    So from what i understood you looking for a way to pass values in downstream functions. You don't evaluate anything in precondition - feature precondition is for UI description. When you declare definition field named "edge" of Query type in the precondition that field is stored in the variable of type map named "definition" and as long as you pass that definition variable to any function all the fields in that definition map will be available for the internals of that function. It has nothing to do with precondition itself, but rather with how data can be passed in the map container, which has the benefit of extensibility when you find that your function requires another argument value you just add that value the new field in the map that you passing to the function instead of editing your function definition in multiple places.
    So if you want to make the length of the edge available for the consumers of definition map you just assigning the to the new field of that map, for example like that:
    definition.edgeLength = evLength(context, {"entities" : definition.edge});
    Now all function that consume definition variable will get the field "edgeLength" with length value.
    The good practice is to organize your functions so that if the expected amount of arguments is big or some of them going to be optional then you declare that subset of arguments as fields of the map value and do the checks of that map argument in the precondition.


  • Options
    jelte_steur814jelte_steur814 Member Posts: 78 PRO
    @Konst_Sh
    Awesome, this was exactly the explanation I was looking for! thank you!
  • Options
    jelte_steur814jelte_steur814 Member Posts: 78 PRO
    I got most of it, except for the 'checking of the map in the precondition'.

    it seems i'm not allowed to evaluate the edgeLenght in the precondition though. I'm already needing the edgelenght in the manipulator change function which is called before the feature body is.

    After lots of googling, I resorted to evaluating the edgelength in an 'edit logic function' and putting it in the precondition through an ALWAYS_HIDDEN length annotation.

    Not sure that's faster or cleaner than just evaluating it twice, but i learnt a lot again... and it works

    that seems to do the trick.
  • Options
    Konst_ShKonst_Sh Member Posts: 42 PRO
    edited March 20
    evLength() is from my point cheap enough to evaluate it twice in editing logic or manipulator change functions and in feature body, caching it with hidden parameter does not worth it. But the idea itself is good and worth to keep in mind for more time-consuming computations. Just remember that if the edge length is changed and the manipulator change or editing logic functions are not triggered (that is in the case of automatic regeneration) and in the feature body you only relying on that cached value then that value will be outdated and you will get the wrong results.

  • Options
    jnewth_onshapejnewth_onshape Member, Onshape Employees Posts: 54
    Can I get you folks to consider posting your questions here as well? https://forum.onshape.com/discussion/23283/hey-featurescripters-what-would-you-like-to-see-in-an-advanced-featurescript-tutorial#latest

    Short version: Im trying to add more advanced FS training. Would like to know more about what issues users are hitting when trying to write FS.

Sign In or Register to comment.