Topic: Effects of holding onto entity already added to database?

[jmaeding]

I am making routines that sometimes show entites via transientmanager, and sometimes draw them.
I'd like to accomplish this by a set of routines to make entites, and a collection list that can either show them as transient or add them to db.
Sometimes, I group the items drawn after they are drawn.
I have always done this by making a list of objectids for items drawn, but it occurred to me that I already have that list since each entity has its objectid as a property.

Only problem is, I am wondering if keeping a list of those entites, even after being added to the db, will mess up autocad's disposal mechanism.  I know to dispose of items used for transient display, that is the old "if you new it, and don't add to db, dispose explicitly".
Any danger in holding onto an entity via some collection, after it was added?

[Glenn R]

Personally, I would use the ObjectId, as it's the value returned using AddNewlyCreatedObject or whatever that function is called.

[Glenn R]

Mind you, if the ents have NOT been added to the dbase and you are just 'new'ing them for other reasons, then you're pretty safe keeping them in a collection of your choice...just remember to destroy them if you don't ADD them.

[jmaeding]

right, the case where I don't add them is easy.
What if i do add them though?
I usually just hold onto the objectid, but why not just hold onto entity that is already part of my list?
In reality, i would be making a group of the entites, then quickly clearing out my collection of entities.

What I am doing for now, is keeping a collection of "EntityItem" objects.
Each item has an entity property, and an objectId prop.
When I add an item to the db, I set the objectid to the entity objectid, then entity prop to null.
That way, I can still use one collection for everything, but have the ability to get rid of references to entites added to the db.

[jmaeding]

boy, it is stuff like this that make .net so dependent on details.
I am now going through my library of "drawline, drawarc, drawthisorthat..." and changing them so they don;t add anything to the db, just return an entity.

I hope people coming from lisp or VBA recognize the power of making entites that you don't add to the db.
Everyone that makes tools likes to show the user what they will get for a given cursor movement, or set of values, and we can now preview things almost for free.  you do have to adjust text size according to screen height though, so its readable.

All this stuff is right in front of us at this site, and several others, but people do not discuss the formation of libraries enough, IMO.
That is the part that took me so long to strategize on when moving from lisp.  Hope thius helps others, i need to get my libraries posted so we can all use them...

[sinc]

You can hang onto the Entity until you commit or abort the transaction.  After that, you shouldn't try to use it.

[jmaeding]

Hi Sinc,
That sounds right to me, but what is the real basis?
Running methods outside of a transaction would crash predictably, and accessing props that depend on a transaction would too.
Would the garbage collector of acad get hampered by my collection holding onto an entity though?

[Glenn R]

Once you add an entity to the dbase, AutoCAD owns it and is responsible for it - you're not. Once the objects are added (through a transaction or whatnot) they are essentially closed by autoCAD - hence you get a returned ObjectId from AddnewlyCreatedObject for later retrieval.

[sinc]

Best thing is to just assume that the Transaction calls Dispose() on your object when you Commit or Abort the Transaction.  Don't touch your DBObject after that point.

If you want to remember a reference to an object, add the ObjectId to a collection.  I sometimes prefer using things like List<ObjectId>, because it has a couple of additional features that are missing from ObjectIdCollection, but an ObjectIdCollection often works, too.  The key is to only hang on to ObjectIds, and only use those after the transaction has been committed or aborted, not the DBObject.

[It's Alive!]

If a new DBObject is successfully added to the database via a transaction, a committed  transaction will close but not dispose the DBObject , an aborted transaction will dispose the DBObject.

The rule is, you should not work with a DBObject that is closed, see the ObjectARX docs under AcDbObject for more info.

ACCESS
Never access a pointer to an object that is closed...

Because of the restrictions on multiple opening of objects, never leave objects open any longer than necessary and always try to open in the least restrictive mode necessary....

[jmaeding]

ok, thanks for the explanations.
For anyone watching this, I am using this class to hold info for each object:
//classes to hold entities
    public class EntityItem
    {
      public IntegerCollection ViewportNumbers = new IntegerCollection();
      public Entity Entity;
      public ObjectId ObjId;
      public int SplineSegs = 0; //needed for drawing smooth plines
      public bool Highlight;

      private EntityItem() { }

      public EntityItem(Entity entity, bool highlight)
      {
        ViewportNumbers.Add(System.Convert.ToInt32(AcAp.GetSystemVariable("CVPORT")));
        Entity = entity;
        Highlight = highlight;
      }
    }
you might laugh at the splinesegs prop, but I don't know how to draw a smoothed pline any other way than setting it, then making the pline.
I'd love to find some way of doing it that was specific to an object, not the state of acad when drawn.
The highlight prop is for transient usage, as the entity does not have such a prop.
Keep in mind the class is intended to hold items that will be shown, and to record what was shown for later use, particularly updating transients or grouping items drawn.

anyway, with the class above, I can hold an entity reference for transient entity usage, or an objectid for items added to the db.
I also have a collection class for EntityItems, which has methods for drawing, ghosting, updating and clearing things out.

[sinc]

Holding both a reference to the Entity and the ObjectId makes me uneasy.

[It's Alive!]

You should be ok with that, I might add a flags to let the consumer know the state of the entity and ObjectId. I might also use IDisposable to handle disposing of the entity.

[sinc]

It makes me uneasy because it would be possible for the Entity.ObjectId and ObjId to end up mismatched, unless care is taken.  It's the sort of thing that can cause future bugs, especially in a team development environment.

If there's really a need to remember both the Entity and the ObjectId, then it might be better to do something like make the ObjId a read-only property that gets set automatically when the Entity is set.  Unless it is the intent that the ObjId can point to something other than the Entity, in which case the Property names are confusing.

[jmaeding]

well, the class has props for both, but I never hold both at the same time.
When an entity gets added to db, the entity prop is set to null, and objectid prop to the one in the db.
The flag idea is a good one, just for sake of clarity, as opposed to having to read my mind on what proprty you should check to determine the state of things.
thx