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

StephenG

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.

EricGauthier

Send an improvement request.

john_mcclary

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. 

StephenG

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_mcclary

@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.

StephenG

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_mcclary

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_sparks

not just the FS that built it, any FS...

john_mcclary

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_sparks

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.