Texplore stores some data in its own configuration file for use the next time the application is started.  The application configuration file is located in the same folder as the Texplore executable file and is named Texplore.exe.config.

Currently, the only persistent information stored in the configuration file is the history of HMI applications to which the TSE program has connected.

Following is a sample configuration file:

<?xml version="1.0" encoding="utf-8"?>

<!-- Configuration file for the Tsentry Screen Explorer -->
<configuration>
  <configSections>
    <!-- Do not edit this section -->
     <section name="TexploreSettings"
      type="TPRI.HMI.Application.Explorer.TexploreSettingsSectionHandler,Texplore" />
  </configSections>

  <appSettings>
  </appSettings>

  <TexploreSettings>
    <AppHistory Host="127.0.0.1" App="TsentryHMI" />
  </TexploreSettings>

</configuration>

The following command line parameters are supported by Texplore:

• /C Host/AppName       
  Automatically connect to the specified TSENTRY host and start the named HMI application.

• /L   
  Run the application using only the locally installed files and assemblies (do not automatically download updated files from the host computer).

• /K   
  Run Texplore in kiosk mode (full-screen without title bar).

• /T path  
  Exit application when user disconnects from host and automatically restart the version of Texplore.exe specified by path.  This parameter should only be used internally by Texplore.

All screens to be displayed in the Texplore environment must conform to the following:

• Each screen must inherit, either directly or indirectly, from the .NET Framework class System.Windows.Forms.Form.

• Each screen must implement the TPRI.Tscreen.ITscreen class interface.

This is required so that the Texplore container can properly interact with and display all custom application screens.

One screen can link to another in a variety of different methods:

• A screen can have a TPRI.HMI.Controls.CmdButton or TPRI.HMI.Controls.LinkLabel object on its display that specifies the ScreenID of the new screen in its LinkedScreen property.

• A screen can raise the ITscreen.ActivateScreen(..) event, which is passed a TPRI.Tscreen.ActivateScreenEventArgs object that specifies the ScreenID of the new screen.

The Texplore application internally has a TPRI.Tscreen.TscreenMgr object that manages navigation between screens.  In either of the cases above, this TscreenMgr object will use the ScreenID name to find the appropriate new screen as follows:

1. If a screen with this ScreenID is already registered in the HMI application configuration file in the AppConfig/ScreenConfig section of the application configuration file.

2. If there is no screen currently registered with the specified ScreenID, the TscreenMgr will check the assembly of the original screen to see if there is a class whose name matches the ScreenID in the same namespace as the original screen.

For instance, suppose the application configuration file has the following <ScreenConfig> section:

<ScreenConfig>
  <Screen ScreenID="MainMenu"
          ClassName="MyNamespace1.MainMenu,MyAssembly1"
          Default="True" />
  <Screen ScreenID="SubMenu"
          ClassName="MyNamespace2.SubMenu,MyAssembly2" />
</ScreenConfig>

When the application is started, a MyNamespace1.MainMenu object will be loaded from the MyAssembly1.dll assembly, assigned a ScreenID of “MainMenu”, and initially presented to the user.  This occurs because this screen is marked with the Default="True" attribute in the HMI configuration file.  At the same time, a MyNamespace2.SubMenu object from the MyAssembly2.dll assembly will be registered with Texplore and its TscreenMgr using the ScreenID of "SubMenu".

If the NtRtMenu screen has a CmdButton on it whose LinkedScreen property is set to “SubMenu”, the TscreenMgr will immediately find the SubMenu screen in its list of registered screens and activate it.

However, if the CmdButton on the MainMenu screen instead specifies “OtherScreen” in its LinkedScreen property, the TscreenMgr will find that there is no screen currently registered with that ScreenID.  Therefore it will check if the MyAssembly1.dll assembly contains a class by the name MyNamespace1.OtherScreen; if it finds one then that screen will be immediately registered, created and activated.  If this class does not exist then the navigation will be canceled.

Consequently, only top-level menus must be specified in the ScreenConfig section of the application configuration file as long as all classes corresponding to screens linked from those menus are located in the same namespace as the top-level menu.

The Texplore application internally has a TPRI.Tsecurity.TsecurityMgr object that manages security for the HMI application.  It is responsible for notifying each screen that is loaded of the currently logged in user and his security access key.  However, it is up to each screen (and each object loaded by each screen) to enable or disable its own components as appropriate based on this security access key.

In addition, the TsecurityMgr object watches the HMI display for inactivity.  If no user interacts with the HMI display for the number of minutes specified by the SessionTimeout key in the AppConfig/LoginConfig section of the HMI application configuration file, the TsecurityMgr will automatically timeout the current login session.  When this happens the Login screen is immediately redisplayed for this user.  At this point if the user reauthenticates again as the original user, he can return to the same point in the HMI application.  If he reauthenticates as a new user then the previous HMI application session will be reset and the user will be log in as if he had not been logged in before.