<configuration>
  <appSettings>
    <directorypaths>
      <!-- Directory path where standard FDT XML Schemas are stored -->
      <add key="FDTXMLSchemas" value=".\FDT XML Schemas" />
    </directorypaths>

    <SchemaValidation>
      <!--
          Defines if XML schema validation should be done. Valid values
          are true or false
          -->
      <add key="DoValidation" value ="false" />
    </SchemaValidation>

    <settings>
      <!-- Specifies enabled FDT versions, "1,2,3" by default -->
      <add key="EnabledFdtVersions" value="1,2,3"/>

      <!--
          Defines the FDT 1.2.x DTM threading model. Depends on this setting DTMs
          are started in RuntimeFrame default (Single Thread Apartment) thread, a shared surrogate
          process, or their own dedicated surrogate processes.
          Valid settings are:
          sharedThread:   DTMs and RuntimeFrame sharing the same thread.
                          The shared thread is normally also the application GUI thread
                          (STA). This setting provides the
                          fastest interaction between RuntimeFrame<=>DTM
                          and DTM<=>DTM GUIs (ActiveX controls).
                          However this model have one major drawback. DTMs
                          can affect the default thread and thus
                          RuntimeFrame and application.
                          Please notice that this setting will be replaced by sharedProcess
                          automatically if the main process is 64bit (which could not load
                          32bit assemblies).
                          Please notice that some old FDT 1.2.x DTM doesn't work in CLR4.
                          Which means using <i>sharedThread</i> in a .Net Framework 4 based
                          frame application may have risk.
          dtmProcessPool: Dedicated surrogate process is started for each DTM Instance.
                          The process name is <i>Fdt1Surrogate.exe</i>.
                          The advantage of this setting is that single DTM
                          can't crash the application process.
                          However interaction between RuntimeFrame<=>DTM
                          and DTM<=>DTM GUI become very slow.
          sharedProcess:  DTMs and RuntimeFrame run in different
                          processes. The process name is <i>Fdt1Surrogate.exe</i>.
                          All DTMs share the same process so if
                          a single DTM crashes its process the application
                          process will not crash. But as all DTMs share
                          the same process the crash will affect all of
                          them.
                          Similar to 'dtmProcessPool' the interaction
                          between RuntimeFrame<=>DTM and DTM<=>DTM GUI
                          becomes very slow.
          processPerDtmType:  Each DTM Type will have it's own surrogate process.
                          All DTM instances of same DTM Type will share one surrogate.
                          The DTM Type will be identified by ProgId of the DTM.
          -->
      <add key="DTMThreadingModel" value="sharedProcess"/>

      <!-- this threading model will be used for FDT 1.2.x DTMs during catalog update -->
      <add key="DTMCatalogUpdateThreadingModel" value="sharedProcess" />

      <!--
          Defines the FDT 2 DTM threading model. Depends on this setting DTMs
          are started in main process (which hosts RuntimeFrame), shared surrogate
          processes, or their own dedicated surrogate processes.
          Valid settings are:
          sharedThread:   DTMs will be loaded in the main process if possible.
                          The word possible at here means the CLR version and platform of
                          the main process is supported by the DTM.
                          For DTMs which do not support the CLR version or platform
                          of the main process, it work same as the sharedProcess mode.
          dtmProcessPool: Dedicated surrogate process is started for each DTM Instance.
                          The process name is <i>Fdt.ClrExtension.Clr*Surrogate.exe</i>.
                          Please notice there are several different surrogate processes
                          for different CLR versions and platforms.
                          This mode could also avoid the conflicts between assembly from
                          different DTMs.
          sharedProcess:  DTMs run in shared surrogate processes.
                          The process name is <i>Fdt.ClrExtension.Clr*Surrogate.exe</i>.
                          Please notice that DTMs may be loaded in different surrogate
                          processes depend on their supported CLR version and platform.
                          All DTMs which support same CLR version and platform share
                          the same surrogate process.
          processPerDtmType:  Each DTM Type will have it's own surrogate process.
                          All DTM instances of same DTM Type will share one surrogate.
                          The DTM Type will be identified by Fdt.Dtm.DtmInfo.Id.
          -->
      <add key="FDT2DTMThreadingModel" value="processPerDtmType"/>

      <!--
          Defines the FDT 3 DTM threading model. Depends on this setting DTMs
          are started in main process (which hosts RuntimeFrame), shared surrogate
          processes, or their own dedicated surrogate processes.
          Valid settings are:
          sharedThread:   DTMs will be loaded in the main process if possible.
                          The word possible at here means the .NET Standard version and platform of
                          the main process is supported by the DTM.
                          For DTMs which do not support the .NET Standard version or platform
                          of the main process, it work same as the sharedProcess mode.
          dtmProcessPool: Dedicated surrogate process is started for each DTM Instance.
                          The process name is <i>Fdt3.ClrExtension.Clr*Surrogate.exe</i>.
                          Please notice there are several different surrogate processes
                          for different .NET Standard versions and platforms.
                          This mode could also avoid the conflicts between assembly from
                          different DTMs.
          sharedProcess:  DTMs run in shared surrogate processes.
                          The process name is <i>Fdt3.ClrExtension.Clr*Surrogate.exe</i>.
                          Please notice that DTMs may be loaded in different surrogate
                          processes depend on their supported .NET Standard version and platform.
                          All DTMs which support same .NET Standard version and platform share
                          the same surrogate process.
          processPerDtmType:  Each DTM Type will have it's own surrogate process.
                          All DTM instances of same DTM Type will share one surrogate.
                          The DTM Type will be identified by Fdt.Dtm.DtmInfo.Id.
          -->
      <add key="FDT3DTMThreadingModel" value="processPerDtmType"/>

      <!--
          Defines the behavior for creating separate AppDomains. Depending on this setting 
          DTM user interfaces will be instantiated in separate AppDomains.
          Valid settings are:
            Off:                        No separate AppDomains will be created and DTMs will be loaded 
                                        into the default AppDomain.   
            
            SharedAppDomain:            All DTM user interfaces are loaded into a shared AppDomain. 
                                        This will be a AppDomain that is separate from the default AppDomain.
                                        This setting can be used when a DTM has conflicts with the Frame Application.
                                       
            OneAppDomainPerDtm:         One AppDomain will be created per DTM that is loaded. DTM user interfaces
                                        of the same DTM will share this AppDomain.
                                        This setting can be used when a DTM has conflicts with other DTMs.
            
            OneAppDomainPerFdtObject:   One AppDomain will be created per instance of a "FDT object". Each DTM user interface
                                        instance will be hosted in a separate AppDomain.
          -->
      <add key="AppDomainCreationMode" value="Off" />

      <!--
          Defines the limit of max. running FDT 1.2.x DTMs. Used to consolidate
          memory usage
          -->
      <add key="RunningDTMLimit" value="20" />

      <!--
          Defines the limit of max. running FDT 2 DTMs. Used to consolidate
          memory usage
          -->
      <add key="RunningFDT2DTMLimit" value="20" />

      <!--
          Defines the limit of max. running FDT 3 DTMs. Used to consolidate
          memory usage
          -->
      <add key="RunningFDT3DTMLimit" value="20" />

      <!-- 
          Specifies the trace level for FDT 2 DTMs.
          Value should be an integer which represents any combination of Fdt.Frame.TraceEventType
          -->
      <add key="Fdt2TraceLevel" value="7" />

      <!-- 
          Specifies the trace level for FDT 3 DTMs.
          Value should be an integer which represents any combination of Fdt.Frame.TraceEventType
          -->
      <add key="Fdt3TraceLevel" value="7" />

      <!-- 
          Indicating whether need start surrogate earlier, if it true, it will start when creating or opening project.
          Otherwise it will start fdt1surrogate process when first time adding a fdt1 DTM to project.
          If it is a true value, can improve the performance when adding a FDT1 DTM to topology for the first time,
          and it only works when DTMThreadingModel is "sharedProcess".
          If it is false, this surrogate process will be start only when first time add a FDT1 DTM to topology.
          -->
      <add key="PrestartFdt1SurrogateProcess" value="true" />

      <!--
          The setting that specifies whether disable collect unused DTMs while heavy operations e.g. importing.
          -->
      <add key="DisableCollectUnusedDtmWhileHeavyOperations" value="true" />

      <!--
          Defines if a DTM can be shut down while it is online.
          You can enable it by setting the value to either true or 1,
          everything else disables it.
          Used to consolidate memory usage.
          -->
      <add key="DTMAllowShutdownWhileOnline" value="false" />

      <!-- 
          Indicating whether the FDT2 surrogate process will be force shutdown when no running DTM in it.
          It was introduced to handle the potential memory leak in FDT2 DTM.
          Set to "true", the surrogate process will be shutdown when there is no running DTM in it.
          Set to "false", the surrogate process will be shutdown when no DTM object is alive. 
          -->
      <add key="ForceShutdownFdt2SurrogateProcessWhileNoRunningDtmInIt" value="true"/>

      <!--  
          The device type information can change as described in FDT1.2.1 specification, Chapter 4.3.13.         
          ValidateDeviceTypeChanges indicates whether a validation is done before a new device type information
          is used and the DeviceTypeInfoChangedEvent is raised.       
          If it is set to true, the validation is done whenever a device type updates. In this case only when the new device
          type is supported by the DTM, the new information will be used and a DeviceTypeInfoChangedEvent will occur.          
          If it is set to false, no validation is done, the new device type information is always used, and an event always 
          occurs whenever a device type changes.           
          This key is introduced because some DTMs provides incorrect device type information via IDtmParameter interface. 
          Having this kind of DTMs in the frame application this key should be set to true.
          -->
      <add key="ValidateDeviceTypeChanges" value="true" />

      <!--
          Defines whether device type identifier is sensitive on device type version.
          When version sensitive is set to true, same device type with different version will be regarded as different ones.
          E.g. in the situation that a project contains a DTM with version 1.1, and the device catalog contains same DTM 
          but version 1.2, the frame will show the DTM as not installed.
          The setting affects the properties ITypeInfoProvider.Identifier and IDTMListItem.IsInstalled.
          -->
      <add key="VersionSensitiveForDeviceType" value="true" />

      <!--
          Defines if the DTM is responsible for the TAG change or the
          frame application.
          If a DTM is responsible the TAG is extracted from the parameter
          XML of the DTM. Otherwise the frame application provides the
          TAGs for the DTMs and ignores different TAGs provided by DTM's
          parameter XML.
          If enabled the DTM is responsible, otherwise the frame
          application.
          You can enable it by setting the value to either true or 1,
          everything else disables it.
          -->
      <add key="DTMTagChangeAllowed" value="true" />

      <!--
			    Defines whether fdtCONTAINER component will support native hosting of .NET ActiveX controls
			    (if not the activeX controls are wrapped by an AxHost).
		    -->
      <add key="DotNetActiveX" value="true" />

      <!-- DTM Bulkdata settings-->
      <dtmBulkData>
        <!--
            Defines if bulk data should be stored in a fix path.
            Valid settings are:
            0:  Defines that no fix root path has to be used.
                The root path defined in the setting "RootPath" is
                ignored and the RuntimeFrame creates a sub-directory for
                each project and stores DTM bulk data in it
                (sub-directory name == project ID).

                Note:   In this case the project name at least provided
                        when creating a new project MUST start with an
                        absolute path as it will be used to determine
                        the root path.

            1:  Defines that a fix root path has to be used.
                That fix root path has to be defined within the setting
                "RootPath" as absolute directory.
            -->
        <add key="UseFixRootPath" value="0"/>

        <!--
            Defines (fix) bulk data directory root path if
            "UseFixRootPath" is set to "1"
            -->
        <add key="RootPath" value="C:\"/>
      </dtmBulkData>

      <!-- FDT 1 Surrogate settings -->
      <fdt1Surrogate>
        <add key="StartUpWait" value="30000"/>
      </fdt1Surrogate>

    </settings>

    <timeouts>
      <!--
          Defines timeout for DTM shutdown requests (response to
          IDtm.PrepareToRelease() calls)
          -->
      <add key="DTMShutdownTimeout" value="5000"/>

      <!--
          Defines timeout for DTM offline requests (response to
          IDtm.PrepareToReleaseCommunication() calls)
          -->
      <add key="DTMOfflineRequestTimeout" value="10000"/>

      <!--
          Defines timeout for DTM close GUI requests (response to
          IDtmApplication::ExitApplication(),
          IDtmActiveXControl::PrepareToRelease() or
          IFdtChannelActiveXControl::PrepareToRelease() calls)
          -->
      <add key="DTMCloseGUIRequestTimeout" value="2500"/>

      <!--
          Defines delay time in ms to wait after DTM is switched to online
          mode (DTM state = communicationSet) before an operation is
          started which requires online connection (i.e.
          Upload/DownloadParameter). 
          This is a workaround necessary for DTMs which can not handle
          this request immediately after online state switch. 
          Value of <= 0 means that no delay time is needed.
          -->
      <add key="DTMOnlineOperationDelay" value="200"/>

      <!--
          Defines delay time in ms to wait before DTM is switched to
          online mode (DTM state = communicationSet) 
          This is a workaround necessary for DTMs which can not handle
          IDtm::SetCommunication() calls immediately after being brought
          in state configured.
          Value of <= 0 means that no delay time is needed.
          -->
      <add key="DTMSetCommunicationDelay" value="0"/>
    </timeouts>

    <userMessage>
      <!--
          Defines if private DTM dialogs are allowed. 
          Note:   Private DTM dialogs may cause problems if
                  DTMThreadingModel != sharedThread (i.e. Message Box may
                  pop-up in the background ...)
          -->
      <add key="allowPrivateDTMDialogs" value="true"/>

      <!-- defines options for the calling of the User Message -->
      <add key="hasGUI" value="true"/>

      <!-- 
          If no GUI is really present, or hasGUI = "0", use this result
          for FDTUserMessage.resultStatus, can be:
              - notSupported
              - denied
              - systemResponse
              - ok
          -->
      <add key="resultStatus" value="denied"/>
    </userMessage>

    <debug>

      <!-- indicates whether to launch the debugger while starting the FDT1 Surrogate Process -->
      <add key="LaunchDebuggerForFdt1SurrogateProcess" value="false"/>

    </debug>
  </appSettings>
</configuration>