Windows 7 64-bit SP1, AutoCAD 2015 SP2 (standard, not Architecture or LT)
We have hit a problem that is unique to 2015, regarding erasing entities. It is not unique to our custom entities - it can be achieved with a standard AutoCAD line.
We have a situation in which the user can select our objects, and with the middle grip, move them - standard stuff (GRIP_STRETCH command). These objects are, however, part of a larger assembly and so if the user moves them out of bounds of the larger assembly, they are erased (think of dragging something out of bounds to dump it).
Up until now - from AuoCAD 2007 through to 2013 (not sure about 2014) - this has worked without any problem. In 2015, however, it is now causing the system to crashes fatally (a 0xC0000005 - access violation).
Due to my other problem of not being able to download the symbols for all Autodesk DLLs (seehttp://forums.autodesk.com/t5/autocad-2013-2014-2015/unable-to-load-important-pdb-files-for-autocad-... I can only tell you that it dies in accore.dll.
If we don't call erase, the crash doesn't happen - but we obviously need to remove that entity somehow. Removing from the database and deleting the now non-DB-resident entity has the same effect - the crash. Even just *calling* erase() on the object - even if we override subErase() and deny the call to the base class (which I believe should not erase it in the first place?) - still causes the crash. Not calling erase() is the only way to stop it.
To simulate this yourselves, create a project and add a reactor derived from AcEditorReactor so that you can have a commandEnded(). During commandEnded(), look for the command being GRIP_STRETCH and then grab and erase any AcDbLine entities in the drawing (it is important not to ask the user to select one, you must grab them yourself). Then start a drawing, add a line, select it to get the grips and move it by its middle grip, triggering that little bit of code - and for us, that causes the crash.
Any suggestions on what is wrong, and how we can fix / overcome this? If we're doing something fundamentally wrong then please let us know.
Solved! Go to Solution.
Solved by autodaug. Go to Solution.
It sounds to me that erasing stuff inside the reactor is dangerous.
Have you thought about creating a command that does the erasing and then sendStringing that command from inside the reactor? Using AcApDocManager::sendStringToExecute()? That way, the erase happens AFTER the reactor has run it's course.
This sounds like a bug, whereby some internal code attempts to open an object, doesn't pass true to allow acdbOpenObject() to succeed on erased objects, then assumes the open succeeded without checking the return value. I recommend to report the bug to Autodesk in hopes of getting it fixed for a future version.
Yep, it's a bug in acad's pickfirst set updating. You can work around it by removing the entity from the pickfirst set before erasing it.
Can't find what you're looking for? Ask the community or share your knowledge.