Issue 23145 - API: cfgmgr2.OSetElementGroupUpdateAccess::XChild
Summary: API: cfgmgr2.OSetElementGroupUpdateAccess::XChild
Status: CLOSED NOT_AN_OOO_ISSUE
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: steffen.grund
QA Contact: issues@api
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-03 12:04 UTC by steffen.grund
Modified: 2017-05-20 09:32 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Test code. Just unpack and follow the README. (4.83 KB, application/octet-stream)
2003-12-03 12:10 UTC, steffen.grund
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description steffen.grund 2003-12-03 12:04:57 UTC
XChild::getParent() does return null, although a parent should be returned.
See attached example code.
Comment 1 steffen.grund 2003-12-03 12:10:02 UTC
Created attachment 11719 [details]
Test code. Just unpack and follow the README.
Comment 2 joerg.barfurth 2003-12-15 13:14:32 UTC
The behavior is correct.

A OSetElement...Access can be in one of two states: Inserted or free.

An inserted object can be accessed as element of a set and returns that set as
its parent. It must not be disposed (the parent is the owner). It can be removed
from the parent (via removeByName) or replaced by another object in the parent
(via replaceByName()) to become free.

A free object is not element of a set and returns NULL for its parent. A freshly
created (via XSingleServiceFactory::createInstance()) object starts life free.
It should be disposed by client code when done. It can be inserted into a set
(via insertByName() or replaceByName()) and then enters the inserted state.

The object in the test case is created free and never inserted, so returning
NULL is correct behavior.
Comment 3 joerg.barfurth 2003-12-15 13:15:52 UTC
Return to submitter as worksforme
Comment 4 joerg.barfurth 2003-12-15 13:17:03 UTC
and changing to resolved again
Comment 5 steffen.grund 2003-12-15 13:48:56 UTC
Reviewed again, and found behaviour to be indeed correct. This means the test
has to be changed.
Comment 6 steffen.grund 2003-12-15 13:56:26 UTC
change test later.
Comment 7 steffen.grund 2005-08-18 14:59:36 UTC
set target correctly.