| |||
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.6 PersistenceIf the version of the Frame Application or the version of the DTM change, persistence (loading of stored projects) can be a problem. A Frame Application must be able to load old datasets and to provide the unchanged dataset to the DTM even the DTM version has changed. A DTM must be able to load old datasets as long as the ClassID and the ProgID of the DTM do not change. If ClassID and ProgID of a DTM have changed, FDT will provide a mechanism to upgrade to the newer DTM. By this way it is possible to load an existing old dataset of a DTM into another DTM object. The new DTM is responsible to convert the dataset accordingly. The new DTM provides information (via the IDtmInformation::GetInformation() method) what DTM datasets it can load (compatibility of dataset). It must support all device types of the old DTM. If the Frame Application recognizes the new DTM, it can inform the user (e.g. "A new compatible DTM was installed, do you want to use the new version instead of the old version?"). If the user confirms the new DTM object is instantiated instead of the old and it loads and converts the old dataset. | ||
© 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. | |||