ObjectARX
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Fatal Crash Erasing Entity Following GRIP_STRETCH - AutoCAD 2015 Only

4 REPLIES 4
SOLVED
Reply
Message 1 of 5
jason.teagle
680 Views, 4 Replies

Fatal Crash Erasing Entity Following GRIP_STRETCH - AutoCAD 2015 Only

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.

4 REPLIES 4
Message 2 of 5

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.

Message 3 of 5

I've found another way around it for now, but this is a pretty good suggestion - I will give it a try and see how well it works. Might be better.
Message 4 of 5
owenwengerd
in reply to: jason.teagle

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.

--
Owen Wengerd
ManuSoft
Message 5 of 5
autodaug
in reply to: owenwengerd

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.

Post to forums  

Autodesk Design & Make Report

”Boost