IDtm::GetFunctions() method information

M&M FDT 1.2.1 Online Specification
IDtm::GetFunctions() method information

Interfaces and Methods - Schemas - FDT Specification - Quicklinks - Abbreviations

4.3.1.3 IDtm::GetFunctions()

This method can be called in the states:

HRESULT GetFunctions (
[in] FdtXmlDocument operationState,
[out, retval] FdtXmlDocument* result
);

Description:

Returns an XML document containing information about standard (defined by applicationID) or additional functionalities (defined by functionId) and documents supported by a DTM

Parameters:

operationState

XML document containing the current operation phase specified by the FDTOperationPhaseSchema

Return Value:

result

XML document containing actual supported functions specified by the DTMFunctionsSchema

Behavior:

This method provides the access to DTM standard functionality, defined by the applicationIDs and specific functionality, which is not within the scope of FDT. This data are available as soon as the DTM is instantiated but the information may change if it is instance specific. That means that the contents of the document can change or can at least be empty after an OnFunctionChanged() event. This event is sent by a DTM if the configuration results in a changed extended functionality. Usually this information is used by the Frame Application to create menus. Functions with user interface are started via IDtmApplication::StartApplication(), IDtmActiveXInformation::GetActiveXGuid() or IDtmActiveXInformation::GetActiveXProgId() and work asynchronous Function calls without user interface are asynchronous as well and are started via InvokeFunctionRequest(). The asynchronous behavior is described at the according chapters. The method additionally provides access to documents provided by a DTM, which can be displayed by the Frame Application or a special viewer program. It is expected that a DTM adapts the provided list of functions according to the role of the current user (see chapter 4.3.1.1). As long as the DTM does not have valid user information (e.g. in state 'running'), it should behave like the user with the least rights ('Observer') is using the DTM. Functions with associated module Ids (so-called module functions) must not be shown directly in the standard context menu of the DTM node. They may appear in a submenu which is associated to a DTM module or in the context menu of a DTM module node. In order to ensure that module functions can be called by the user, the Frame Application should provide a submenu 'Modules' in the context menu of the DTM node or provide appropriate context menus for DTM modules or offer these functions by other means. The DTM has to ensure that all accessible module functions (enabled and not hidden) are valid. If the active module collection of a DTM varies due to configuration changes, the DTM must call OnFunctionChanged() to notify the Frame Application. That means the Frame Application is not responsible for matching the given module Ids to the list of the existing modules returned by IDtmParameter::GetParameters().

Comments:

If a Frame Application does not support the operation phases ('notSupported') the DTM should provide all functions based on the current state (e.g. 'communication set') and the current user role. If the DTM wants to limit the number of opened ActiveX controls, it should disable the corresponding functions. If an ActiveX is closed, the DTM has to enable the function again.

© by M&M Software GmbH, parts of this website taken from FDT Interface Specification Version 1.2.1, © by FDT Group, AISBL.
This website is published for support of M&M products as granted in license conditions, chapter 2.1.
Last updated 2015-02-05 15:17
Email: FDT Technical Support Line.