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.

Why does "Move to new subassembly", "Create new subassembly" create the ASSY in doc's root folder?

StephenGStephenG Member Posts: 367 ✭✭✭
When I create a new assembly using the "+" (Insert New Element) it creates the new assembly in the current folder tab.

However, if I create a new assembly using the Context Menu "Move to new subassembly", or "Create new subassembly" the assembly element tab is created in the document's root folder. 

It seems obvious the new assembly should be created in the active folder tab which would be consistent with what happens when the "Insert new element" is used.

This behavior does not make sense to me.

Answers

  • EricGauthierEricGauthier Member Posts: 73 ✭✭✭
    Send an improvement request.
  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,890 PRO
    Agreed, this should create in the current folder.

    I've noticed the last few times I have imported a step file, it puts the result in the root now. It didn't used to do this.
    I haven't tested this thoroughly though. I could be doing something wrong, or remembering it differently. 
  • StephenGStephenG Member Posts: 367 ✭✭✭
    There is another aspect to creating an element (Document Tab) that runs contrary to the long standing standard behavior for creating "new" named things.  When a new named thing pops into existence the standard behavior is to allow the creator to immediately assign it a meaningful name. For example, creating a folder in either Windows, or MacOS creates the folder with a default name that can be either accepted, or replaced with something more meaningful. The practice of assigning meaningful names to things is something that should be encouraged and providing the user a simple immediate mechanism to accomplish that should exist. The meaningful name is usually present in mind of the creator at the moment the element tab is created so that is the best opportunity to capture it; not later with a manual rename operation.

    The above statement applies only to element tab creation, but the same issue essentially exists for named parts in a Part Studio; the default "Part N" name is not a very meaning/useful name. I find after the fact renaming of parts to be a chore. I realize for a Part Studio the problem is more complex than creating document tabs, especially if the feature can create multiple parts.
      


  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,890 PRO
    @StephenG
    I would agree with tab names, but not so much with part names, as they come in and out of existence during the modeling phase, especially with splits and booleans

    Also, because Onshape will lock-up any property if it has been written to at least once, preventing you from using featurescript setProperty.
    currently I am using a FS to name all my parts that is parametric, any naming behavior would break that ability.
  • StephenGStephenG Member Posts: 367 ✭✭✭
    Are you saying if I rename a part (change its meta data name property) its name cannot be subsequently modified by the featurescript that caused the part to come into existence?

    I agree, features that have the capacity to create multiple parts presents a real challenge to assigning meaningful names at part creation, and also a when a modification to the feature results in a different number of parts being created.

    Thinking out loud here... one thought I had was to have the part's default name be based on the name of the feature that created it. For example, for mirroring a part the newly created part name would be "Mirror N" instead of "Part N". For features that create multiple parts/surfaces/curves a count would be added to the part name. For example, using the split feature to split a part into 3 parts, the default part names would be "Split N.1", Split N.2", "Split N.3". Just an idea.

    Interesting observation...
    If I use a feature that creates multiple parts, manually rename the resultant parts, change the feature to create less parts, then change the feature again to create more parts, it remembers the names of the parts that "disappeared" and assigns them to the parts that "reappear". Not sure if this is always the case. This behavior seems to align with what you said about a feature property that has been changed [by the user] cannot be changed by [regen of] the featurescript.  


  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,890 PRO
    StephenG said:
    Are you saying if I rename a part (change its meta data name property) its name cannot be subsequently modified by the featurescript that caused the part to come into existence?

    yup
  • owen_sparksowen_sparks Member, Developers Posts: 2,660 PRO
    not just the FS that built it, any FS...
    Business Systems and Configuration Controller
    HWM-Water Ltd
  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,890 PRO
    I'm pretty sure it's only blocked if you hand edit a property.

    I've been experimenting with this the last week with @MBartlett21's help. And I've added and removed FS to parts and they have updated. Maybe i should experiment with an entirery new fs to see if that second one doesn't write
  • owen_sparksowen_sparks Member, Developers Posts: 2,660 PRO
    Concur on the hand edited.
    I thought we had a workaround with a transform copy in place, read old part metadata, squirt to copy metadata and then delete original part, but there is no "get" method for part properties, only "set".
    Grrr.
    Owen S.
    Business Systems and Configuration Controller
    HWM-Water Ltd
Sign In or Register to comment.