Important: |
---|
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
The UPnP AV Framework supports the addition of custom actions to the services defined by the UPnP AV DCP.
Calling Custom Actions
To call a custom action from a control point, call InvokeVendorAction. As it does with predefined actions, the UPnP AV Framework packages the InvokeVendorActionparameters, sends them to the service using UPnP, and calls the InvokeVendorActionmethod on the appropriate device service class.
For more information, see UPnP AV DCP Documentation.
Custom Action Parameters
To support the passing of varying numbers of parameters in custom actions, the InvokeVendorActionmethod signature uses an instance of the COM DISPPARAMSstructure. DISPPARAMScan contain an arbitrary number of parameters.
For more information about using DISPPARAMSinstances, see Passing Parameters.
Virtual Services and the First Custom Action Parameters
The AVTransport and RenderingControl services can support multiple virtual services. At the UPnP network level, each service is identified by an instance ID that is passed to all actions. The UPnP AV Framework hides this detail and enables device implementers to handle virtual instances by creating instances of classes that derive from the top-level interface classes, like IAVTransport, and so do not require the use of instance IDs.
A control point that calls a custom action does not need to do anything with instance IDs. The UPnP AV Framework automatically adds the instance ID as the first parameter of the DISPPARAMSstructure before it sends the action invocation request to the device.
The UPnP AV Framework ensures that action invocations are routed to the appropriate device instance and does not require processing the instance ID. However, it does not remove the instance ID from the DISPPARAMSstructure. Therefore, device implementation code in virtual services should ignore the first parameter in the DISPPARAMSstructure.