Mutiply Owned Objects?

[PSI_Tech]

*Warning* Multiply owned object, handle "1AB"

I am currently getting the above message in the cad editor when creating my custom entity. I currently have a custom AcDbObject derived class which is a profile definition stored in the NOD. I also have a custom SweepEntity derived from AcDbEntity which has an AcDbHardPointerId to reference the profile. As I understand it, the profile is owned by the dictionary, but because of the AcDbHardPointerId member in the sweep entity, does that mean that the sweep entity is the owner of the profile object as well?

What is the "proper" technique for creating relationships between objects in a dictionary to entities?

Any tips from the pros?

Mike

[owenwengerd]

Your hard pointer does not confer ownership. What is the object that is the subject of the error? Which object is supposed to own it? What does the object return from ownerId()?

[PSI_Tech]

Thanks for the reply Owen, and as you say, the hard pointer doesn't confer ownership and I didn't think it did but I couldn't think of what else could be causing this warning. I did however use the ARXDBG program after adding my entity to look up the handles the warning was refering to. It turns out that it is warning about the handles for the dictionary and the profile contained therein. The peculiar thing here is, I bring the profile into the current drawing from another drawing by using WblockCloneObjects(...). It is almost as if the original ownership isn't forgotten when the cloning of the dictionary and the profile is completed. Is there a special technique used to clone objects from a dictionary in one drawing  and bring them into the current drawing database? Is there a special call to say "forgot your past ownerships" to the objects being cloned?

Mike

[owenwengerd]

There is nothing "special" that you have to do, but there are many things that could have gone wrong for many different reasons. Since you're dealing with a custom object, odds are pretty good that the source of the problem is in your implementation of the object. If you do the detective work to find out what exactly is wrong, you'll have a better idea of where to look. For starters, check whether the object and its owner agree on who the owner is. If not, then figure out why not.

[PSI_Tech]

I am not sure how to check "if they both agree who the owner is". Looking at the ARXDBG application, my profile object clearly states the expected dictionary is the owner object. Is there anyway to find out which other objects the profile thinks maybe its owner. I find it strange that Autocad can warn about multiply owned objects but does not indicate who the owners are.

Mike 

[owenwengerd]

The dictionary files out a hard/soft ownerhsip id to let you know that it thinks it owns the target object. The target object's ownerId() returns the id of the object it thinks is its owner. ArxDbg is useful, but I think you'll need to explore the problem at runtime using diagnostics built into the code itself. If that fails to produce results, the next step should be to follow the standard troubleshooting steps of creating a new project from scratch and adding code until you can reproduce the problem in a minimal project.

[PSI_Tech]

How can I see what ids the dictionaries are filing out? I wrote a basic test arx/dbx as you suggested and I still get the warning and still cannot figure out why. Once loaded, the arx has two commands, ExportDictionaryTest and ImportDictionaryTest. The export creates an instance of a custom object and adds it to a dictionary which is added to the named objects dictionary. At the end of the export, the drawing is saved. The other command, opens the previously saved drawing, opens the named objects dictionary, opens the custom dictionary, gets the "TestEntity" object id and wblockClones the object to the named objects dictionary in the current drawing.

I have attached this test application.

Mike

[PSI_Tech]

Further to my previous post, I have noticed, using ARXDBG, that the new dictionary object is in fact added twice so does have two owners. For some reason, it is added to both the root NOD and the custom dictionary. I am only sending the object's id to the WblockCloneObjects(...) function. In the dwgIn/OutFiles, if its is kWblockCloneFiler, I write out the owner id. I thought this was the intent so that when wblocking the object, it knows where to put the clone.

/// ---------------------------------------------------------------------------------------------------------
/// <summary> </summary>
/// ---------------------------------------------------------------------------------------------------------
Acad::ErrorStatus DetailerObject::dwgInFields(AcDbDwgFiler* filer)
{
	Acad::ErrorStatus es = AcDbObject::dwgInFields(filer);
	if (es != Acad::eOk)
		return es;

	// Simply read-in the id to keep it in sync.
	if (filer->filerType() == AcDb::kWblockCloneFiler)
	{
		AcDbHardPointerId id;
		filer->readHardPointerId(&id);
	}

	if (filer->filerType() == AcDb::kIdXlateFiler)
		return es;

	filer->readString(mDbId);
	filer->readString(mTag);
	filer->readString(mDescription);

	return filer->filerStatus();
}

 Any ideas?

Mike

[PSI_Tech]

lol, I showed dwgInFields, not out. The following is the dwgOutFields(...).

Acad::ErrorStatus DetailerObject::dwgOutFields(AcDbDwgFiler* filer)
{
    Acad::ErrorStatus es = AcDbObject::dwgOutFields(filer);
    if(es != Acad::eOk)
        return es;

    if(filer->filerType() == AcDb::kWblockCloneFiler)
        filer->writeHardPointerId(ownerId());

    ....
    ....
}

[owenwengerd]

The writing and reading of the object's ownerId() is useless code and should be removed. I doubt that's the cause of your problem, though. I looked at your test code, and it looks like you're adding the owned object to the array passed to wblockCloneObjects(), which should result in exactly what you describe. You should only clone the owner, which will clone its own children.

[PSI_Tech]

>>> The writing and reading of the object's ownerId() is useless code

Well, I read somewhere that it was required for the WblockCloneFiler to know where to place the object in the dictionary.

>>> You should only clone the owner, which will clone its own children.

That is what I initialy thought but wouldn't I then only be adding the NOD's object id? This doesn't work.

I have to rethink this through because nothing I try is working as expected. I need to be able to import profiles and store them into the named objects dictionary. These profiles are setup and stored in other drawings, the user may create one drawing per profile or have many profiles in a single drawing. Regardless, I need to store them in a single dictionary in the NOD. Why can't I just open the source drawing, locate this dictionary, iterate over its entries, and use copyFrom() and store them in this drawing? I tried this before and the copyFrom seem to leave invalid objectid's.....

Mike

[owenwengerd]

If you're cloning a profile, then that should be the one and only object id in your id array when calling wblockCloneObjects. It should certainly work.

[PSI_Tech]

Sorry Owen, I am now confused. Here is the idea. I have an application where the user can create user defined profiles (custom objects) which are added to a dictionary called "DetailerProfiles" residing in the NOD. Now the user wants to create a swept solid (custom entity) which references a profile. The user selects the profile definition from the list and the application opens the associated drawing, imports the profile into the current drawing by placing it into the "DetailerProfiles" dictionary in the current databases NOD. In this circumstance, can I:

1. use copyFrom and add the resulting copy to the dictionary.
2. add the profiles object id (from the source database) to the WblockCloneObjects(...) method.
3. add the DetailerProfiles dictionary object id  (from the source database) to the WblockCloneObjects(...) method.
4. add the NOD object id  (from the source database) to the WblockCloneObjects(...) method.

Sorry, but I am getting really frusterated with this. It seems like this should be a trivial task, but it is not turning out that way for sure.

Thanks for your time......

Mike

[owenwengerd]

You should add the profile object id, and only that id, to the array passed to wblockCloneObjects. Nothing else.

[PSI_Tech]

That is all I do add. Not sure why the duplicate entries happen then. I will have to re-write some code and see what happens I guess.

-Mike

[owenwengerd]

Sorry, I thought you had added more than one object id to the array.

You asked earlier how to determine the owner id. You can use ArxDbg's filer test to see what is being filed. The owner id will be a soft pointer id near the beginning of the output. As I said, it's usually better to build in your own diagnostic output to test things in context at runtime.

I don't have time at the moment to build and test your sample project, but hopefully someone from Autodesk can take a look.

[PSI_Tech]

This issue is a huge block for progress to my project. By any chance, is there anyone that can reply with an example of "importing" a dictionary resident object from an external drawing to "this" that works. Even a .net example would suffice.

Anyone?

Mike