Fantastic. I will check these out. Thank you for bring them to my attention. I read many blogs but somehow missed this.

Yves, Il est possible de conserver ce comportement (avec Linework) tout en évitant un effacement accidentel avec de loutil Modifier Je te remercie - Erik [It’s possible to keep this behavior (with linework) and still prevent accidental deletion in the Modify tool]

Thanks. I dont imagine things will be reverted given the new tools offer a great deal of new capability. More likely would be some combination or unification that tries to accommodate all common work-flows.

Very Lively

I'm not just interested in the way people have this set but more why one would change it from one setting to another. It would be simple enough to enable drag on first pick for annotations, and mass forms and disable for model elements and inside faces of model elements as well as links if this satisfied the majority of use cases.

Everyone is entitled to their opinions and if anything it sheds some light on the difficulty of making any change in this product. I do agree any changes that affect selection should be considered together and when there are many different opinions and use cases options can help. It would be a large research project to go through every category to find which might be dragged or not to remove the need for this configuration. Other related topics are link selection and underlay. I may post separately to discuss these.

completely agree. Internal workings should not hold up progress

Good points. We are probably the heaviest journal user so your points there are well known though I would not use it as an excuse unless its also an issue for customers.

Im curious what you are dragging or the specific use case. Drag seems very inaccurate unless you use temp dims.

So far my suspicions are confirmed but I like to get as much feedback as possible - even before an alpha or beta. Im sure we created this setting to mitigate risk where there was less clarity. This will often work but puts the product on a path to complexity.

All these suggestions are popular. Ill share potential requirements Ive gathered in a future post. thank you

Ill look to see if I or anyone here has some tips for this condition. I would also suggest a post to AUGI which is a fantastic community of Revit experts.

Very common suggestion. Ill post on known issues and potential requirements in the days ahead.

Sure. That would work as well. You can sketch a small footprint roof with two slope defining lines. This would work as long as the slope is constant like the example.

There are many other ways for sure. I did cover shape editing: http://insidethefactory.typepad.com/my_weblog/2010/02/shape-editing.html Each method has advantages and disadvantages but I can look to cover them in a future post.

Good examples. The toolkit in use is partially to blame for some of these behaviors. VG is a high traffic dialog.

Good one. Its certainty easier to act on the thing in front of you than to hunt for it in list form.

A perfect example of an unwanted behavior that comes from a third party toolkit used through much of the Revit UI - most places grids appear. Replacing this is a larger project but one we may need to do at some point to advance the UI.

This would be handled from the element. It should make a reference available to the command. Ill see if this issue is logged.

Excellent suggestion. I should have pointed out that the origin for loadable content is the same as the family origin but for hard coded elements like cameras the centroid may not be the best choice.

Good point. Center is more specific.

I understand the desire for this and it exists in other Autodesk products so its known to be helpful. Ill record your comments in our internal request database. Thank you.

This might have slipped in during a 2011 subscription update. Sometimes I know we think these are more just bug fixes rather than a feature but Ill work to ensure they make release notes.

Cool. The dialogs do support icons and they should appear in specific cases. If the warning is just informational typically there is a blue dot with white i but most dialogs are of this kind and so we omit it. The Yellow Exclamation Mark is used when there is a risk of data loss or significant time lost. The red X would only be a more severe version of this. In general if you see an icon it should get more attention and if you dont see an icon the risk is minor. If you know of cases that dont conform to this certainly let us know. We are always trying to make these more effective and easier to understand. I did a whole post on task dialogs a while back.

I hear you. Well keep at it. Ill check on the ts behavior for views. They have few type properties, but yes it should be enabled.