| |||
Interfaces and Methods - Schemas - FDT Specification - Quicklinks - Abbreviations | |||
| Up to FDT Specification 3.1 Abstract 3.2 Introduction 3.3 Component Interoperability 3.4 FDT Type Library 3.5 DTM and Device Versions 3.6 Persistence 3.7 Nested Communication 3.7.1 Data Exchange 3.7.2 Communication Channel Upgrade 3.7.3 Scenarios 3.7.4 OnAddChild 3.8 Implementation Hints 3.8.1 Interfaces 3.8.2 Persistence | 3.5 DTM and Device VersionsWhen providing a new DTM for a new major FDT version, it is highly recommended to use a new ClassID and ProgID. A DTM handling a new major FDT version requires that the container has installed an appropriate new COM type library, typically incompatible to the previous major FDT version. Only this new ClassID and ProgID should register for the category ID according to the appropriate FDT major version. If ClassID and ProgID of a DTM have changed, FDT will provide a mechanism to upgrade to the newer DTM (see also chapter 3.6 and 6.25). Within it’s device catalog information (as DTMDeviceType elements in the IDtmInformation document) a new DTM version is able to provide the same list or a subset of the devices of the old DTM version. In this case a FDT Frame Application will handle the two versions of a DTM as any other DTMs able to handle the same field device as two distinguished DTMs. A DTM of a higher FDT version which does not use a new ClassID and ProgID must support at least all DTMDeviceTypes of that were supported by previous versions of this DTM. | ||
© 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. | |||