Hi Joe. The problem you note below (the wrong object type,
not any crash that results from it), is as old as ActiveX, and
has been discussed here many times in the past.
When a COM wrapper for an object exists, and AutoCAD
replaces that object with another object of a different type,
and also exchanges the object ids; xdata and extension
dictionaries of the old and new objects, any subsequent
attempt to access the object via COM will result in the
existing COM wrapper, which is the wrong type.
The same problem can be seen when breaking a circle with
an existing COM wrapper, then looking at the resulting ARC
in the Properties palette, which think's its a circle.
When you do this:
(vlax-dump-object (vlax-ename->vla-object (car (entsel))))
without calling vlax-release-object on the result returned
by vlax-ename->vla-object, the COM wrapper will not be
released and destroyed until the next GC, and hence, the
properties palette gets the old COM wrapper of the wrong
type.
Passing the object to vlax-release-object (and deselecting
it in the Properties palette) should release the COM wrapper,
and if there are no additional outstanding references to it,
the COM wrapper will be destroyed, and the next attempt to
access the object via COM will result in the creation of a new
wrapper of the correct type.
--
http://www.caddzone.com
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com
"Joe Burke" wrote in message news:5215376@discussion.autodesk.com...
Steve,
Thanks for the info. I guess it's somewhat comforting to know the problem only occurs
when a break point is very close to the first or last vertex of a lwpline.
Regarding the crash after CONVERTPOLY, it may be related to the following. Select a
lwpline.
Command: CONVERTPOLY
Enter polyline conversion option [Heavy/Light] : H
Select objects: 1 found
Select objects:
1 polyline objects converted.
Which indicates a lwpline was converted to a heavy pline.
Select the converted pline. Properties says it is a Polyline, meaning a lwpline. Do a
dump on the object.
Command: (vlax-dump-object (vlax-ename->vla-object (car (entsel))))
Select object: ; IAcadLWPolyline: AutoCAD Lightweight Polyline Interface
; Property values:
; Application (RO) = Exception occurred
; Area (RO) = AutoCAD.Application: Invalid class
; Closed = AutoCAD.Application: Invalid class
; ConstantWidth = AutoCAD.Application: Invalid class
; Coordinate = ...Indexed contents not shown...
; Coordinates = AutoCAD.Application: Invalid class
; Document (RO) = #
; Elevation = AutoCAD.Application: Invalid class
; Handle (RO) = "57C"
; HasExtensionDictionary (RO) = 0
; Hyperlinks (RO) = #
; Layer = "0"
; Length (RO) = AutoCAD.Application: Invalid class
; Linetype = "ByLayer"
; LinetypeGeneration = AutoCAD.Application: Invalid class
; LinetypeScale = 1.0
; Lineweight = -1
; Normal = AutoCAD.Application: Invalid class
; ObjectID (RO) = 2126309408
; ObjectName (RO) = "AcDb2dPolyline"
; OwnerID (RO) = 2125507832
; PlotStyleName = "ByLayer"
; Thickness = AutoCAD.Application: Invalid class
; TrueColor = #
; Visible = -1
T
Obviously not good. AFAIK the only way to make the object right is save, close, and
reopen the file. Vla-update doesn't help. After save, close, open...
Command: (vlax-dump-object (vlax-ename->vla-object (car (entsel))))
Select object: ; IAcadPolyline: AutoCAD Polyline Interface
; Property values:
; Application (RO) = #
; Area (RO) = 2.07357e+007
; Closed = 0
; ConstantWidth = 0.0
; Coordinate = ...Indexed contents not shown...
; Coordinates = (38445.2 -26900.0 0.0 60463.2 -26900.0 0.0 ... )
; Document (RO) = #
; Elevation = 0.0
; Handle (RO) = "57C"
; HasExtensionDictionary (RO) = 0
; Hyperlinks (RO) = #
; Layer = "0"
; Length (RO) = 40624.0
; Linetype = "ByLayer"
; LinetypeGeneration = 0
; LinetypeScale = 1.0
; Lineweight = -1
; Normal = (0.0 0.0 1.0)
; ObjectID (RO) = 2125993888
; ObjectName (RO) = "AcDb2dPolyline"
; OwnerID (RO) = 2126339320
; PlotStyleName = "ByLayer"
; Thickness = 0.0
; TrueColor = #
; Type = 0
; Visible = -1
T
Now ACAD sees the converted lwpline as a heavy pline.
Keeping in mind, CONVERTPOLY is currently an unsupported command.
Joe Burke
wrote in message news:5214757@discussion.autodesk.com...
Yes, it's a bug. Eliminate the red herrings of osnaps getting in the way and the
command sequence failing to use the First option before first point selection, and
the bug is still there, whether it is in code or at the command line.
The end of the red line is 0.0025 below the end of the white LWP, so the result of
the break should be two LWPs, one 0.0025 long above the red line and one from the
green line downwards. Instead, the result is no LWP at all.
I suspect AutoCAD is trying to be clever with cases where a break would leave a tiny
LWP at the end. If the LWP would be tiny, AutoCAD just erases it to prevent leaving
little unintended "dots" around the drawing. However, the logic goes wrong somewhere
and *both* LWPs are erased.
Interestingly, I managed to crash AutoCAD 2007 while playing with this. After doing a
CONVERTPOLY to see if this occurs with heavy plines too, the second time I did this I
got this command-line message during the break:
TRIM 2: Could not find polyline end copy point
immediately followed by:
FATAL ERROR: Unhandled Access Violation Reading 0x0004 Exception at 64555170h
I haven't managed to reproduce this yet. Normally, AutoCAD will break the heavy pline
correctly at the green line, also eliminating the tiny overshoot pline. This gives
support to my theory that AutoCAD is trying to do this with LWPs too, but is just
getting the logic wrong.
I'm not sure how AutoCAD works out its fuzz factor to determine if the LWP is "tiny"
or not. If the distance is increased to 0.0027, the break works correctly. 0.0026
does not. I haven't bothered to work out the exact cut-off point, because it's not
absolute anyway. If you scale the objects up by 1000 so the distance is 2.5, the
problem still occurs.
