Trim and Extend, trimming back, extending, too far

[Mamma Jamma]

I'm having an issue with Trim and Extend. Specifically with the shortcut method of hitting "Enter" instead if selecting objects. It's trimming back to beyond the closest object and/or extending beyond the closest object, but not in a way that's predictable. It doesn't seem to matter what the nearest object is (block entity, pline, etc.) And, yes, they are all on the same plane or whatever. All flat as pancakes, and the regular Trim/Select, etc is working OK.

I think I have something for the wishlist....don't muck up the stuff that works!

[Mike.Perry]

Hi

Within all DWG files or just the odd one ?

Is it possible to post a DWG file that exhibits the behaviour you have described...

Have a good one, Mike

[sinc]

2007 has problems TRIMming and EXTENDing to polylines, especially polylines in XREF's. I think it might have other problems, too.

I think they changed something. I seem to remember that it used to be impossible to select individual objects in XREF's to use as cutting objects. Now you can select objects in XREF's to use as cutting objects. When they made this change, I think they introduced a bug.

Usually, if you select the item explicitly, you can TRIM or EXTEND to it. But the SELECT ALL option definitely has problems.

It just seems to be another one of those annoying things that are part of life in 2007... ;)

[jaberwok]

The same applies to standard blocks - now only the individual item that was clicked to select the block acts as a trimming object instead of all parts within the block.
Why do they keep fixing things that aren't broken? :banghead:

[Mike.Perry]

Hi

The following might be of some interest, then again it might not be...

ID: TS1056860 - Unable to trim polylines when the cutting edge is a block (http://usa.autodesk.com/adsk/servlet/ps/item?siteID=123112&id=7236900&linkID=2475323)

ID: TS67419 - Select the whole block instead of a single object during some commands (http://usa.autodesk.com/adsk/servlet/ps/item?siteID=123112&id=2863929&linkID=2475323)

Have a good one, Mike

[Mamma Jamma]

Thank you.
Convertpoly seemed to fix the issue, when I change the polylines to heavy (so far anyway). I don't really understand what caused this problem, when all I'm doing is editing entities that were already on the drawing and all created in 2005 (or 2004).
Again - Autodesk, Don't fix it if it ain't broke!

[sinc]

Anyone know if there are any negative repurcussions from using heavy polylines instead of LWPolylines (especially in Land Desktop)?

It seems strange that Autodesk's "fix" is to stop using LWPolylines... Why did they create LWPolylines in the first place, if the oldstyle polylines can be substituted, and work better?

[Mamma Jamma]

It pretty much stinks that I'm having to convert new polylines to "heavy" (whatever the heck that means - they look exactly the same) in order to quickly trim back to my block objects. And
I find it interesting that the command of Convertpoly is no where to be found in help. It's not in my 2007 "Bible" either. I must say, I'm becoming more disillusioned every day...

[.T.]

Anyone know if there are any negative repurcussions from using heavy polylines instead of LWPolylines (especially in Land Desktop)?

It seems strange that Autodesk's "fix" is to stop using LWPolylines... Why did they create LWPolylines in the first place, if the oldstyle polylines can be substituted, and work better?

If I remember correctly, heavy vs. light refers to the way the data is stored for the plines in the database. In a heavy, each vertex is stored as a vertex entity, whereas the light ones are stored as a single entity with the data more like in a list that tell where the vertexes (or is it verti?) are. This makes the light ones take less disk space. If you do (entget (car (entsel))) on a heavy and a light, you will see the difference between the two.