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.
Best Of
Re: Is there a way to create a customize mate?
Short answer is no, but you can often achieve this using limits...
Or using an intermediate "dummy part" and two separate mates: for example a sketch surface as a slider and a ball mate to that surface would provide what you are looking for (I think?)
Or using an intermediate "dummy part" and two separate mates: for example a sketch surface as a slider and a ball mate to that surface would provide what you are looking for (I think?)
Feature Request: Parent Document Column (More Columns In General)
Please add a column to the search table that shows the parent document of the part/assembly/drawing. This would be very useful when cleaning up "rogue" documents.
Also, more columns in general would be nice. The search table is pretty sparse. Ideally, any metadata should be available as an optional column.
Caching of context state through feature regeneration.
Some features combine a few requirements: to perform a quite expensive operations like boolean/ split and then be responsive to some frequent user interface edits, which are not changing the result of previously invoked operations and can be quite cheap but because they trigger the full evaluation of the feature body the responsiveness of that code is pretty bad overall.
Today we can do some caching of computational data via editing logic function and hidden definition parameters, which is nice but can't preserve context changes. So I propose we consider some mechanism of context-level caching where the context-changing operation itself would take care about that during user edit "session". That mechanism can be disabled during automatic regeneration if the overhead of cache validation on feature bounds is high, and can work only if the feature dialog is open. If something like that be available we could even store some expensive computational data in context variables instead of evaluating it in editing logic.
Konst_Sh
3