How to remove an object from the properties manager programmatically?

[jason.teagle]

We have a number of custom objects which have other custom objects as embedded members, using AcDbObjectIds. The objects have COM wrappers for the property manager, and the sub-objects can often have wrappers as well. Thus, when you use a crossing window to select entities, both end up selected for display.

When you have objects of multiple types selected, you can select a subset by choosing the type from the drop-down list, and properties common to that subset are then displayed.

The problem I have is that when selecting one of the parent objects in this manner (while sub-objects are also selected) and changing a property that causes some or all of those sub-objects to become erased, trying to deselect everything when the property change is complete results in a fatal crash under 2012. If the sub-objects that get erased were not selected at the time, this wouldn't be a problem, but we can't exactly tell users "pick the parent objects one by one" as that simply isn't practical (and they shouldn't have to).

Although I can get a hold of the property manager object, it doesn't appear to have any way of finding out what is currently selected for display (including what subset is selected from the drop-down list), or to manipulate those items in any way.

Does anyone know how to / if it's possible to programmatically remove an object from the property manager's list so that we can remove erased objects and prevent the crash? Removing the underlying custom object from the selection set is not enough - in fact it's automatic when the object is erased. It's the COM wrapper object created to support the property manager that needs to be cleanly removed and destroyed.

Hope that made sense.

[owenwengerd]

Erasing an object doesn't delete it from memory, so that alone is not a reason for the COM wrapper to trigger a crash. The crash could be caused by an AutoCAD bug, but it's more likely to be caused by a bug in your own code.

[jason.teagle]

I might have agreed with you until recently, since our code is far from infallible, except for the following:

(a) We can reproduce this problem simply by erasing a standard AcDbBlockReference sub-object - in which case the wrapper is the one provided by AutoDesk, not ours, thus eliminating our code from the equation.

(b) This doesn't happen in 2010 and 2011, which means they have either changed something that broke our code, or else they tightened up on something they were lax on before.

We will, of course, continue looking to see if we can find the cause in our code, but when you have customers waiting for a release, holding it back in the hope we'll find it just doesn't cut it. Sometimes the only way to solve a problem is to work around it in the interim - hence, being able to remove wrapper objects from the properties manager.

It's probably a case of the properties manager wasn't designed to support objects it is displaying being erased...

[owenwengerd]

From your description, it certainly sounds like Autodesk's bug. Have you tested 2012 SP1 to see if anything changed? If not, I may be able to help. Please email me to discuss it offline.

[fenton.webb]

Here's a suggestion for you...

We recently posted all of the AutoCAD debug PDB's to www.autodesk.com/symbols

1) Find your customer's acminidump.dmp file in their %TMP% folder

2) Start Visual Studio 2008 or 2010

3) Goto Tools->Options->Debugging->Symbols

4) Add http://www.autodesk.com/symbols and all paths that include your own application pdb files to the symbol paths, make sure the symbols will load (turn off any manual setting)

5) Load the acminidump.dmp into Visual Studio as a project file

6) Hit F5 to start debugging

Visual Studio will show you the call stack that caused the crash...

I hope this helps.

Fenton Webb

Autodesk Developer Network