yang686526

oddbentity::close()
oddbentity::close()
hi. i am a japanese. i am sorry in poor english.
the result that an object was opened is received by the program which used odt3.x with a smart pointer.
it was considerate here.
the means which closes the object that it opened specifically doesn't exist.
is it good if the part doing pentity->close() how is written again?
when is an object actually closed?
is an object closed automatically when the reference count of the object becomes a zero?
but, it is supposed to be sometimes troublesome with that.
because, pentity->cancel() isn't made.

the object is closed when its reference counter becomes 1. one reference is from database internals. so if reference counter is 1 - nothing points to it except database. you need not call close() function.
transaction resident objects (which were opened after starttransaction() was called) will be closed at outermost transaction end. transaction references opened objects.
where is no oddbobject::cancel() function. aborttransaction() should be used to roll back modifications made after starttransaction() call.
if you need to roll back changes made after objects were closed and notifications invoked you can use undo functionality.
btw, in posted toolkit version aborttransaction() and undo do not work but they are very close to be finished.
sergey slezkin

hi.
i also have same question about oddbobject::close()/cancel().
i know that using transaction is recommended scheme, and the fact, i usually take it, if possible.
although, in the real, a lot of arx'es don't use transaction. and in addition, unless if i mis-understand, current arx cannot use any transactions if target database is not assosiated with a document.
on the one hand, it's seemed to be very important strategy that how to take attantions from many arx developers in the world, and how to re-use existing arx sources for odt v3 deployment.
all arx developers are strongly aducated like 'all things you opened must be closed, or else, unexpected result will happen.'
in ideal, you are quitely right.
but in the real, i think, not always the best way it is.
and at the last, when i make dummy oddbobject::close() method, how is the most near implementation?
for example, after open it, only decrementing the reference count by one is the most near implementation for 'close()'?
thank you.
---
arx developer,
hyogo japan.

using smart pointers you need not call close() explicitly. the object will be closed in smart pointer destructor or if you assign a new value (maybe 0) to the smart pointer.
object is not closed untill the last smart pointer pointing to it is destroyed or assigned another value.
if your goal is to compile and run a code written for autocad's objectarx without its editing, implementing oddbobject::close() method will not be sufficient. probably writing some set of wrapper functions will be required.
objectarx open function returns acdbobject* pointer.
oddbobjectid: penobject() returns smart pointer so code below will not work.
oddbobject *pobj = id.openobject();
pobj->dosomething()// error. object is closed
// because it's not referenced
// by smart pointer any more
correct code:
{
oddbobjectptr pobj = id.openobject();
pobj->dosomething();
} // here object is closed in smart pointer destructor
or:
{
oddbobjectptr pobj = id.openobject();
pobj->dosomething();
pobj = 0; // object is closed
...
}
note that no invalid smart pointer can exist.
to emulate arx like behaviour open function returning "normal", not smart pointer is required. it should "addref" the object. close function in such case should call "release" method.
but using smart pointers and close() implemented via release() - decrementing reference counter is not safe - if you decrement reference counter manually in your close() implementation you need to increment it manually in your open() implementation.
sergey slezkin

thank you for detailed explanation.
i found great hint from your explanation:
> or:
>
> {
> oddbobjectptr pobj = id.openobject();
> pobj->dosomething();
> pobj = 0; // object is closed
> ...
> }
by this way, it can be possible to provide alternate acdbobject::close() method.
thank you very much.