Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape, CAD, maker project and design.

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.

Queried entity type evaluation

konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 644 ✭✭✭✭
Now if your query supports several entity types (geometry types, body types) and you need to process them differently you have to create a number of constructions like
if (try silent evSomethig is Somenting) {}
else if (try silent evSomethingElse is SomethingElse) {}
and it seems to be not very elegant for the task of finding out what entity/geometry/body contains the query.
Am I missing something or there is a reason to ask for implementation of function like evQueryContetntType(query) which should return a map like {"entityType":entityType, "bodyType": bodyType, ''geometryType":geometryType} for a query refferensing single entity.


  • kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers Posts: 370
    Generally speaking we prefer to use queries rather than evaluations to solve filtering problems. They are more efficient, they're lazily run, they don't give the user data which can go out of date, and (hopefully) they involve writing less FeatureScript.

    For your case, can e.g. qGeometry() be used to do the job? If not, why not? We can certainly look into adding more queries like a qGeometry with multiple types, or a qHasAxis or qHasDirection to correspond with evAxis and evDirection.

    For something like evSurfaceDefinition, I'd say your construction actually is good, canonical FeatureScript. One alternative is to wrap each in e.g. if(evaluateQuery(qGeometry(...)) != [] ). I think you'll find that the performance is about the same (since the ev functions themselves will fail early).

  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 644 ✭✭✭✭
    edited August 2017
    For example in my Measure distance extended FS for angle evaluation a have to extract direction vector from entities that have axis and normal vector for planes, and i have to wrap it into if-else tests. For two entities I had to write four tests - this doesn't look like reducing amount of code. And i can remember several more cases when i would like explicitly know queried entity type instead of bulky tests, at least so is my thoughts.

  • ilya_baranilya_baran Onshape Employees, Developers Posts: 794
    The request makes sense to me.  The modifications I would make to the proposal are: not restrict it to one entity, but return an array of maps, and also include the transient query in each map.  This may also be a good way of returning other cheap-to-get per-entity info, such as whether it is modifiable, construction geometry, or belongs to a sketch.
    Ilya Baran \ Director of FeatureScript \ Onshape Inc
  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 644 ✭✭✭✭
    @ilya_baran, thank you for your attention, should I make this an improvement request?
  • ilya_baranilya_baran Onshape Employees, Developers Posts: 794
    Yes, please.  That'll ensure that you get a notification email when one of us implements it.
    Ilya Baran \ Director of FeatureScript \ Onshape Inc
  • Jake_RosenfeldJake_Rosenfeld Moderator, Onshape Employees, Developers Posts: 908
    edited August 2017
    @konstantin_shiriazdanov ;

    Go check out 'extractDirection(...)' in 'topoloyUtils.fs', as well as 'QueryFilterCompund.ALLOWS_DIRECTION' in 'query.fs'.  It doesn't solve the wider problem you are asking about, but it is a built-in way of doing what you want in Measure Distance.
    Jake Rosenfeld - Modeling Team
  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 644 ✭✭✭✭
    thanks @Jake_Rosenfeld, it would somehow simplify the code
Sign In or Register to comment.