STAAD.Pro Ideas Portal

Welcome to the STAAD.Pro Ideas portal. The purpose of this site is to post ideas for enhancements and new features. We value your feedback and our team regularly reviews your suggestions for consideration in future releases.

You have 3 options for providing feedback:

  1. Vote for an existing Idea. The popularity of an Idea helps us understand its importance to our users.

  2. Comment on an existing Idea. We want to hear your unique point of view.

  3. Add a new Idea. If no existing Idea describes what you would like, add a new one!

When you Vote, Comment, or Add an idea you will also be subscribed to that Idea and will receive status updates. Please note that we may merge or rename Ideas for clarity. Thank you for your support and feedback, it is always appreciated!

Add a new idea Subscribe
Status Future consideration
Created by Randy Killian
Created on Jan 1, 2021

RELATED IDEAS

Retain Design Parameters in Merged Members

When members are merged any design parameters they have are lost. If members that have the same design parameters are merged, the newly created member should retain those parameters. Also, if the members had code checks done on them before the merge, the new member should remain in the CHECK CODE command.

The current way of merging is so inconvenient that I seldom use it once I have assigned design parameters. I delete member(s) then change the connectivity of the remaining member, then get rid of any nodes left over. This is horribly inefficient but it's easier than going back and assigning design parameters after they are lost due to merging.

  • Admin
    Carlos Aguera
    Reply
    |     Aug 22, 2022

    Thank you for posting this idea. Finding a good way to determine the attributes that should be retained when members are merged is certainly a good idea. The challenge though is to determine what is the right action to take.

    1) If an attribute is assigned to one but not the other(s)

    2) If an attribute is assigned with different values on the various members


    Rather than remove parameters, would a suitable compromise be that a choice is offered to say which member the parameters are taken from?