DDF's can be represented as a tree structure and so naturally lead themselves to be described by recursion which most people find difficult to understand. Reading a ddf from the supplied adapter is fairly easy, the problems are the recursive nature of the solution that describes the ddf.

The two important methods on CSmlDmAdapter are DDFStructureL and the other one is DDFVersionL. The DDFStructureL function takes as an arguement, an implementation for an MSmlDmDDFObject. This will be the root node for the DDF and typically this will be the name of the DDF  e.g. AP for access points)

As the adapter builds the DDF, it will call back on the methods of MSmlDmDDFObject to set the
various parameters that describe the node. You will need to derive a class from this and
CBase and provide implementations to all the methods of the MSmlDmDDFObject.
It is up to you to track the relationships between the nodes, so each time AddChildObjectL
or AddChildObjectGroupL is called, it will require a new instance of the object implementing 
the MSmlDmDDFObject interface to be created. This new node will be added as a child of the
current node. If the DDF tree is being stored then it will be up to you to keep track of
the objects you create.
 
In order to construct the tree, AddChildObjectL is used to add a named node and
AddChildObjectGroupL is used to add an anonymous or ununamed node (these are denoted as
<x> is in the ddf specification). Both of these functions return a new instance of an
object implementing the MSmlDmDDFObject.

One of the tricky aspects to this is that some of the adapters put their name in the ecom data and others do not, so generally you need to read the DDF for the adapter in order to get the name of the adapter if you are using it to set specific settings.

A partial example to read the ddf..
For the purposes of this example, we will assume that we already have an adapter
instantiated via RECOMSession::CreateImplementationL

//This class is used to store the ddf
class CDmDDFNode : public CBase, public MSmlDmDDFObject
    {
public:
    CDMDDFNode();
    ~CDMDDFNode()
        {
        iChildren.ResetAndDestroy();
        }
           
public: // MSmlDmDDFObject
    .... // Implementations of the pure virtual
         // get and set methods of MSmlDmDDFObject
    MSmlDmDDFObject& AddChildObjectGroupL()
        {
        return AddChildObjectL(_L8("<x>"));
        }
       
    MSmDmDDFObject& AddChildObjectL(const TDesC8& aNodeName)
        {
        CDmDDFNode* node = new (ELeave) CDmDDFNode;
        CleanupStack::PushL(node);
        iChildren.AppendL(node);
        CleanupStack::Pop(node);
        return *node;
        }
       
private:
    RPointerArray<CDMDDFNode> iChildren;   
    };

When calling DDFStructure...

CDMDDFNode* root = new (ELeave) CDMDDFNode;
CleanupStack::PushL(root);
adapter->DDFStructureL(*root);
CleanupStack::Pop(root);

const TDesC8& name= node->Name(); // the root node is the adapter name.
....

Once the DDF has been read, it is then possible to get the version of the DDF.
The DDF version is important as it allows differentiation of features as well as identifying
possible issues with bugs fixed from earlier releases.

CBufFlat* buf = CBufFlat::NewL(64);
CleanupStack::PushL(buf);
adapter->DDFVersionL(*buf);
HBufC8* DDFVersion = buf->Ptr(0).AllocL();
// .... create store this somewhere
CleanupStack::PopAndDestroy(2, buf);

Next Part...
Setting simple single values...

Nigel brown reminided me that I had planned to post up a whole lot of stuff on working with the Device management adapter API's. Its written but not posted so the next couple of weeks will be devoted to this as documentation is sparse, though Jukka has posted some examples on the wiki.

 (More)