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

Instantiate and Query Preservation?

chadstoltzfuschadstoltzfus Member, Developers, csevp Posts: 130 PRO
I am attempting to store queries(of edges) in a FeatureScript attribute of parts, and then derive those parts into another context. It seems to not preserve the query when using the instantiate function and I'm guessing that's because opMergeContexts() doesn't go into FeatureScript attributes. Is there a way I can go and merge the contexts of the queries stored in FeatureScript attributes or do I have to do some other kind of workaround? 
Applications Developer at Premier Custom Built
chadstoltzfus@premiercb.com

Comments

  • Options
    lanalana Onshape Employees Posts: 693
    @chadstoltzfus
    The attributes should stay, I'm surprised if they were lost in opMergeContexts() but the queries stashed in those attributes would not be valid in the context calling merge. Notice that opMergeContexts can accept trackThroughMerge array of queries and return array of corresponding evaluation results after merge. That would be a better way of handling this.

  • Options
    chadstoltzfuschadstoltzfus Member, Developers, csevp Posts: 130 PRO
    How would I go about getting those queries? I'd imagine I would have to do something like before deriving in the parts, query the parts in the other context (the context of the part studio I am importing) and then get the FS attributes from all of those queried parts, check if they have a query stored in their attributes, and then put those queries in trackThroughMerge. Is there a way to query in a context other than what the current feature is being executed in? 
    Applications Developer at Premier Custom Built
    chadstoltzfus@premiercb.com
  • Options
    kevin_o_toole_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 565
    edited August 2020
    As Lana says, attributes should be preserved in instantiated parts. For instance, qAttributeQuery() should find entities with attributes correctly.

    The likely issue you're seeing here is that getAttributes(...{"entities" : oldQuery )) doesn't work because oldQuery doesn't resolve to anything in the new context. That can be solved by replacing oldQuery with a working query (such as a specific qAttributeQuery()), or by passing in oldQuery in the "trackThroughMerge" argument to opMergeContexts, or the "queriesToTrack" option of derive().

    To your last question: If you're rolling your own code with opMergeContexts, it's perfectly possible to resolve a query in another context e.g.
    const otherContext is Context = somePartStudio.buildFunction(somePartStudio.configuration);
    const evaluated = evaluateQuery(otherContext, oldQuery); // or any other evaluation
    ..but I wouldn't recommend writing code like that for most applications, since the high-level instantiator (or the less-high-level derive()) are easier to work with than low-level code like above.
  • Options
    chadstoltzfuschadstoltzfus Member, Developers, csevp Posts: 130 PRO
    Right, the attributes are staying, it's just that a query that might be stored in an attribute is not resolving to anything. Like you said the issue I'm encountering is when using getAttributes(...{"entities" : oldQuery )). So when you say replace oldQuery with a working query, I guess what you're suggesting is instead of assigning a query of the edge to the body owning that edge, I should create some kind of attribute pattern that identifies that edge and then query for that edge after importing. Also bear in mind I'm using instantiate and not derive so I don't have a queriesToTrack option available (unless I write my own instantiate).
    Applications Developer at Premier Custom Built
    chadstoltzfus@premiercb.com
  • Options
    lanalana Onshape Employees Posts: 693
    I also would not recommend switching from use of instantiator to direct call to opMergeContexts. If you can mark the edges you want to access with a special attribute, please do that and use qAtttributeQuery() as Kevin proposed.
  • Options
    MBartlett21MBartlett21 Member, OS Professional, Developers Posts: 2,034 EDU
    @chadstoltzfus
    @kevin_o_toole_1
    @lana

    I did modify my copy of instantiator.fs a little while ago to enable tracking through the instantiate.
    This was so I could track a sketch region through the instantiate (The feature I was using it for is also in the document)
    See the link below:
    https://cad.onshape.com/documents/2ad339efe44128f5171291fa/w/400f27295a4447ca3ac2d504/e/30d9197c261899fd3f9c28f4
    mb - draftsman - also FS author: View FeatureScripts
    IR for AS/NZS 1100
  • Options
    lanalana Onshape Employees Posts: 693
    I remembered seeing a user-modified instantiator! That looks correct and seems like it will be useful. Thank you @MBartlett21 ! We should look into exposing this functionality in std.
  • Options
    MBartlett21MBartlett21 Member, OS Professional, Developers Posts: 2,034 EDU
    :)
    mb - draftsman - also FS author: View FeatureScripts
    IR for AS/NZS 1100
Sign In or Register to comment.