Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- 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.
Showing what's in a query
billy2
Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,068 PRO
A few questions actually:
1. I suppose this isn't allowed:
2. how do you show what's in your query I'm using:
It would be nice to highlight on the model what you've captured.
3. the million dollar question:
So it works for 1 instance
But fails at 2 instances
In my code
and
These should be unique identifiers and it should work.
The math is right because I can manually rotate geometry
What's the red circle, is that the last selection list? If you edit the feature, will it highlight the last query?
If you can't follow this, please let me know how to present a coding problem
1. I suppose this isn't allowed:
var i, j, k;
2. how do you show what's in your query I'm using:
debug(context, qNthElement(qCreatedBy(id + "cylinder" + cnt, EntityType.EDGE), 1));
It would be nice to highlight on the model what you've captured.
3. the million dollar question:
So it works for 1 instance
But fails at 2 instances
In my code
fCylinder(context, id + "cylinder" + cnt, {
and
opDraft(context, id + "draft1" + cnt, {
These should be unique identifiers and it should work.
The math is right because I can manually rotate geometry
What's the red circle, is that the last selection list? If you edit the feature, will it highlight the last query?
If you can't follow this, please let me know how to present a coding problem
0
Comments
For others trying to figure it out:
-all this code does is loop through and makes 3 cylinders defined by a variable definition.count.
-the highlighted blue code gets the 3 faces by the id of the feature id + "cylinder" + cnt
-then I look through this query and pick the 3rd element which is qNthElement(query, 2)
-then add that to a debug statement
edit your feature and it highlights all the faces that were queried in the script:
This way uses a point and captures anything that's coincident with the point which should be a very robust query technique.
The debugged faces using qContainsPoint:
If you just want to display console output (like printing the angles above) you can just use print() or println().
On diagnosing errors, the most helpful feedback you'll get will be in the FeatureScript notices flyout. Including that flyout with errors in your screenshot will likely contain the most helpful information for others to help you diagnose the problem.
Your particular error involves something that's definitely not apparent from the documentation: How to manage hierarchical ids.
Here's a quick summary: When you make an id of the form
id + foo + bar
, you want "foo" to be the main group of operations, and "bar" to be a smaller, sub-operation. That way, querying for, sayqCreatedBy(id + foo)
alone will return things created byid + foo + bar
, and byid + foo + bar2
, etc. There are technical reasons why features and operations cannot currently be added under an existing id after that id has been "closed", i.e. another feature has been created under a different id.In your case, you were creating geometry under
id + "cylinder"
, then underid + "draft"
, then back underid + "cylinder"
, which throws the error described above. Since you're building each arm of the star individually, a more functional id structure would put the variablecnt
first, and build a cylinder, a draft, and a fillet on each arm as part of that id.Thus, the fix is to change all instances of
<b>id + "cylinder" + cnt</b>
to<b>id + cnt + "cylinder"</b>
(and the same for draft/fillet).I agree that the error we present in this case isn't helpful, which is something we'd like to eventually address.
Finally, you're spot on about the robustness of queries. qNthElement is hard to rely on in the general case, while qContainsPoint, combined with the qCreatedBy, should give you the right thing every time.
Working code: