The NtRtMgr is the primary manager task of the Tsentry system.  It provides the following services:

•  Allocate data dictionary global shared memory region

• Populate memory resident data dictionary with disk resident information

• Allocate global shared memory regions

• Initialize and restore contents of global shared memory regions

• Start and monitor all process tasks

• Display current status of all process tasks

• Display recent contents of LogMsg message queue

• Start/Restart/Suspend/Stop/Configure processes via console window

• Shutdown system when requested

The Tsentry system can be started by executing the NtRtMgr task and passing the name of the system initialization file. 

The following configuration files control the operation of the startup task:

• System initialization file       

• Process initialization file

• Data dictionary definition file

• Data dictionary variable initialization file

• LogMsg initialization file

This system initialization file defines:

• The remaining fully qualified initialization file names to be used by the startup process:

• Process initialization file

• Data dictionary definition file

• Data dictionary variable initialization file

• LogMsg initialization file

• System-wide and application parameters

An example file follows:

# ------------------------------------------------------------------------
#  A Foil Mill Initialization File

[IniFiles]
#define the Data Dictionary Structure definition file
DDStruct=d:\locNtRt\afm\pif\afmStruct.ini

#define the Data Dictionary variables definition file
DDVars=d:\locNtRt\afm\pif\afmVars.ini

#define the process definition file
Procs=d:\locNtRt\afm\pif\afmProcs.ini

[AppParams]
# System Name
SystemName=A Foil Mill

# Shutdown executable
ShutdownExe=d:\locNtRt\tpriNtRt\bin\NtRtStop.exe

# Splash screen picture file
SplashPicture=d:\locNtRt\afm\Pif\afmLogo.bmp

# GUI Options: '&'-delimited list of one of more of the following strings:
#    NoConsole           Do not display the NtRtMgr screen
#    NoStopSystem        Do not allow the interactive user to stop the NtRtMgr
#    NoExecProcess       Do not allow the interactive user to 
#                           start/stop/suspend/resume processes
#    NoEditProcess       Do not allow the user to edit process parameters
#    NoProcessMenu       Do not display any menu via right clicks on the
#                           process list
#    NoConsoleLogMsg     Do not allow the user to insert LogMsgs from the console
#    TrayIcon            Minimize the NtRtMgr screen to a tray icon
GuiOptions=

# Option not to query if system should kill existing processes on startup
#QueryKillExistingProcesses=No

# Directory for NtRtCmd files
NtRtCmdPath=D:\locNtRt\afm\NtRtCmd\

# ------------------------------------------------------------------------

This configuration file controls which processes will be started as part of the real-time control system.  The fully qualified file name is passed to the startup process as the first command line parameter.  An example process.ini file that contains line format definitions as comments follows:

# -------------------------------------------------------------------------------
[Process]
# This is the process.ini file for the Application system.
# This file is read by the startup process at system startup.
# Processes are started in the order they are listed in this file. 
# This file is also read by each process at startup (by method PrIni)
#
# The format of the process.ini file is as follows:
#
# Lines beginning with a "#" are comments
#
#  AppName        - Application name of the process that is to be run.
#
#  BinName        - Fully qualified system executable binary file name of
#                   the process associated with AppName
#
#  Uses NtRt      - Flag indicating if this process uses the tpriNtRt library
#                   for process management
#
#  Priority       - the priority that the task is supposed to run at.
#                   Options for Priority are:
#                       0 - 15   Standard Windows NT dynamic priority (mode=Std)
#                                 0 = lowest
#                                15 = Highest
#                      16 - 31   Standard Windows NT realtime priority (mode=Std)
#                                16 = Lowest
#                                31 = Highest
#                       0 -127   Hard Real-Time (mode=Rt)
#                                 0 = Lowest
#                                127= Highest
#
#  Timer Delay    - Initial Timer delay (milliseconds) before first 
#                   execution.  Zero if no timer specified.
#
#  Timer Interval - RepRate Timer Interval in milliseconds.
#                   Zero if no timer specified.
#
#  Run Mode       - indicates whether a task is to run as "standard" or
#                   "realtime" process.
#
#  Auto-Restart   - "yes" or "no"; specifies if the process is to be
#                   automatically restarted should it is unexpectedly
#                   terminated.
#
#  MemLock        - Lock in memory option
#                   "yes" indicates locked in memory
#                   "no" indicates not locked in memory
#                   All Hard Real-Time processes are always
#                   locked in memory.
#
#  Trap Crash     - Combination of character flags specifying how process 
#                   crashes/exceptions should be handled
#                   N = Default handling (windows displays message box)
#                   T = Terminate process
#                   D = Log description
#                   S = Try to find symbol and source line
#                   W = Walk back along stack and dump info
#                   R = Dump register values
#                   Y = Default 'Yes' = Same as 'TDS'
#
#  Debug Mode     - Debug mode / level. Values are process dependent.
#                   Normally lower values indicate less debug and logging
#                   Higher values indicate more debug and logging
#
#  Startup Delay  - Defines delay time (milliseconds) before starting
#                   this process.  A negative value indicates that this
#                   process should not be automatically started at system
#                   startup.  
#                   Negative Startup Delay's are (usually) used for the
#                   startup process itself and for any demand process
#                   that needs to run periodically, but not when
#                   the system is started.
#
#  Init Wait      - Defines the delay time (milliseconds) to allow for 
#                   this process to initialize itself before proceeding
#                   to the next process in the list.
#
#  Kill Wait      - Defines the delay time (milliseconds) to allow for 
#                   this process to react to a deactivation request and
#                   gracefully exit before it is forced to terminate.
#                   Negative times indicate that the process will never
#                   be terminated without its permission.
#
#  Pulse Timeout  - Defines the timeout (milliseconds) for the process
#                   pulse.  Every time the process calls PrWait it resets
#                   an internal timer to this value.  The NtRtPulse
#                   decrements this timer and kills the process if it
#                   expires.
#
#  CTail            Command tail to be passed to the process
#                   This parameter is optional
#                   If the command tail is supplied, it must
#                   be enclosed in double quotes
#
# ---------------------------------------------------------------------------

# ---------------------------------------------------------------------------
#
# GroupName     Init
#               Active
#
# ---------------------------------------------------------------------------
[AppGroups]
Application     Y


# ---------------------------------------------------------------------------
#
# AppName BinName          Uses Prty Tmr  Rep  Run Re-  Mem Trp Dbg StUp Init Kill Pls CTail
#         (FileName)       NtRt      Dly  Rate Mod strt Lck Crs Lvl Dly  Wait Wait TO
#
[System]
NtRtMgr   D:\xx\NtRtMgr.exe   Y 10   500  500  Std No   Y   N   30  0    0    -1   0
NtRtMtr   D:\xx\NtRtMtr.exe   Y 31   10   10   Std Yes  Y   T   30  0    0    -1   0
RtxTcpip  C:\ww\rtxtcpip.rtss N 120  1000 1000 Rt  No   Y   T   0   -1   0    500  0   "zz.ini"
GsmOpcSvr D:\xx\GsmOpcSvr.exe Y 10   500  500  Std No   Y   T   30  0    0    5000 0
TrendMgr  D:\xx\TrendMgr.exe  Y 10   200  200  Std No   Y   T   30  -1   3000 3000 0   "zz.ini"
TrendGsm  D:\xx\TrendGsm.rtss Y 20   20   20   Rt  Yes  Y   T   30  -1   5000 5000 0   "zz.ini"
TrendSrv  D:\xx\TrendSrv.exe  Y 10   1000 1000 Std Yes  Y   T   30  -1   0    5000 0

[Application]
# Insert each of the application processes here
RTSSTask  D:\yy\RTSSTask.rtss Y 20   100  100  Rt  No   Y   A   30  0    5000 5000 2000
W32Task   D:\yy\Win32Task.exe Y 8    100  100  Std No   Y   A   30  0    0    5000 2000

# ---------------------------------------------------------------------------

This is the first of two files used by the NtRtMgr to initialize the data dictionary.  It is the output of the data dictionary builder process GsmPifBld, which parses the C/C++ global common header files to generate this flat ASCII definition of shared memory.  For most purposes you do not need to examine the contents of this file.  It is further described in the Data Dictionary section.

Data dictionary variable

This is the second of two files used by the NtRtMgr to initialize the data dictionary.  This file defines the various global common segments used by the system and any ‘special’ variables contained therein.  It is further described in the Data Dictionary section.

LogMsg initialization file

This configuration file initializes the LogMsg subsystem.  It is described in detail in the Libraries section.

The NtRtMgr task can be stopped by either clicking the Stop System button or the Windows ‘X’, both in the upper right hand corner of the window.

Shutting down the NtRtMgr process performs the following tasks:

1. Request orderly and graceful stop of all processes

2. Forcibly terminate tasks that do not stop via graceful request

3. Save contents of global shared memory regions

4. Deallocate global shared memory regions

5. Stop operation of Startup task

The NtRtSvc task is used to run Tsentry as a system service.  This allows Tsentry to start automatically on system startup, continue to run whether or not the console is logged in, and gracefully stop upon system shutdown. 

The NtRtSvc service can be installed by running the following command from a DOS command prompt:

D:\locNtRt\tpriNtRt\bin\NtRtSvc -install D:\locNtRt\tpriNtRt\bin\NtRtMgr.exe D:\locNtRt\sys\pif\sys.ini

where D:\locNtRt is your root installation directory and sys is your system ID.

This adds the entry ‘Tsentry Manager Service’ to the list of services in your system.  By default, the service is configured for:

• Automatic startup

• Log On as local Tsentry user

It is strongly suggested that a separate user (e.g. username NtRtMgr) be created to run the NtRtSvc service instead of running as the Local System account for several reasons:

• Access to appropriate directories can more easily be managed if the system is started under an account other than the Local System account

• Access to the GsmOpcSvr is greatly simplified since the GsmOpcSvr can be configured to run under this same account while preventing any users from having DCOM launch permissions. 

This new user however must have administrative rights to perform functions such as creating and sharing global common segments, starting RTSS tasks, etc.

The NtRtSvc service can be started in several ways:

• If the Startup Type is configured as Automatic, the NtRtSvc will automatically start when the system is booted.

• From the Service Manager (Control Panel->Administrative Tools->Services), right-click on the ‘Tsentry Manager Service’ and choose ‘Start’.

• From a command prompt, type ‘net start NtRtSvc’. 

You must have administrative rights to manually start the NtRtSvc service via either of the last two options above.

The NtRtSvc service can be stopped in several ways:

• Shutdown Windows.  The NtRtSvc will automatically detect the system shutdown and gracefully stop itself and all Tsentry processes.

• Execute the NtRtStop process.

• From the Service Manager (Control Panel->Administrative Tools->Services), right-click on the ‘Tsentry Manager Service’ and choose ‘Stop’.

• From a command prompt, type ‘net stop NtRtSvc’. 

You must have administrative rights to manually stop the NtRtSvc service via either of the last two options above.

The current command line that the NtRtSvc service will start can be displayed by running the following command from a DOS command prompt: 

D:\locNtRt\tpriNtRt\bin\NtRtSvc -display

where D:\locNtRt is your root installation directory.

The NtRtSvc service can be removed by running the following command from a DOS command prompt:

D:\locNtRt\tpriNtRt\bin\NtRtSvc -remove

where D:\locNtRt is your root installation directory.

The NtRtStop process is used to kill all Tsentry tasks.  This performs the same shutdown sequence as NtRtMgr does when it shuts down.

The NtRtMtr task is designed to monitor the remaining Win32 processes and ensure that they behave properly.  It is effectively a worker thread for the NtRtMgr manager task, but because its duties require that it execute at the highest Win32 priority (31), it must be run as a separate process from the NtRtMgr GUI. 

Currently the NtRtMtr task provides the following services:

• Monitor all Win32 tasks to ensure that their respective pulse timers do not expire

• Request termination of any Win32 tasks whose pulse times do expire

The ProbeSvr task is a variable data server for Tsentry global shared memory.  Upon startup, the ProbeSvr process opens a listen socket on TCP/IP port number 2252 and waits for connections from remote clients across the network.  In most cases, these clients are Texplore browser sessions looking to retrieve global common variables from the host TSENTRY system. 

Once a client connects and exchanges initialization information with the server, the client can request a list of global common variables from the ProbeSvr process.  The host will then periodically send the values of each of these variables back to the client on a periodic basis or at any time that the variable value changes on the host. 

In addition, clients may choose to write new values for the requested variables back to the host system.  These new values will be immediately written directly into the corresponding global common variables.  The ProbeSvr process supports logging of custom messages when a client changes the value of a variable in global common by logging the change data to a specified LogMsg queue.  A custom application can then be written to process the change data logged to this queue and log the data as appropriate for the application.  The following data is available for logging:

• The fully qualified name of variable that was changed

• Date and time of the change

• Both old and new values of the variable

• Size (in bytes) and type (variant type) of the variable

• Array dimensions of the variable

• Username of individual (according to the client system) that made the change

• Computer name from which the user client connected to the host system (IP address or DNS name)

• Screen name (or equivalent) from which the change was issued on the client system

• Description of the change as indicated by the client system

Custom probe sources can be defined to allow the ProbeSvr process to serve local application data outside of global shared memory to HMI clients.  For example, the TelePro Thickness and Flatness Monitor system implements a custom probe source in order to display data from historical coil reports on Texplore screens.

Custom probe sources are implemented as a DLL that is dynamically loaded by the ProbeSvr executable at runtime.  The list of custom probe sources is defined in the process initialization file.

Clients can request a variable from a custom probe source by prefixing the variable name with the name of the probe source surrounded by forward slashes.  For example, requesting “/MyProbeSource/MyVariable” will tell the ProbeSvr process to request a variable named MyVariable from the DLL associated with the MyProbeSource custom probe source.

The DLL for a custom probe source must implement two functions.  The first function is called when the ProbeSvr process receives a request for a variable associated with the custom probe source:

//------------------------------------------------------------------------
//
// Function Name: AddVariable
//
// Description:
//    Add a probe variable to the custom probe source.
//
// Calling Format:
//    int fstatus = AddVariable(pVar);
//       where:
//          tpriProbeSrcVar *pVar = pointer to probe variable
//
// Return Value:
//    This function always returns zero.
//
//    In order to successfully add  the variable, the custom DLL must call
//    each of the following methods of the passed tpriProbeSrcVar object:
//     - SetSize(int newSize), where newSize > 0
//     - SetType(int newType), where newType != VT_INVALID
//     - SetDataPtr(void *newData), where newData points to a memory
//          buffer allocated with GlobalAlloc(..) which will not be
//          freed until the RemoveVariable(..) function is called
//     - SetArrayDimensions(int newCount, int *newDimensions) if the
//          returned buffer points to an array of data
//
// Notes:
//    When the function is called, the name of the variable can be
//    determined by calling pVar->GetName().
//
//------------------------------------------------------------------------

The second function is called when the ProbeSvr process determines that a variable is no longer required by any client application and can be removed from the custom probe source:

//------------------------------------------------------------------------
//
// Function Name: RemoveVariable
//
// Description:
//    Remove a probe variable from the custom probe source.
//
// Calling Format:
//    int fstatus = RemoveVariable(pVar);
//       where:
//          tpriProbeSrcVar *pVar = pointer to probe variable
//
// Return Value:
//    This function always returns zero.
//
// Notes:
//    None.
//
//------------------------------------------------------------------------

This initialization file for the ProbeSvr process currently defines:

• Local host address to which the ProbeSvr server socket should bind.  This is required on systems with multiple network interface cards, only one of which should be used by the ProbeSvr.

• The LogMsg queue used for basic text logging when a client changes the value of a variable in global common.  If this queue is not Tsentry’s default LogMsg queue then it must be defined in the sysLogs.ini file so that it is actually created when the TSENTRY system is started.

• The LogMsg queue used for logging custom messages when a client changes the value of a variable in global common.  This queue must also be defined in the sysLogs.ini file so that it is actually created when the TSENTRY system is started.

• Any custom probe sources and the associated DLL used to handle variable requests.

An example file follows:

# ------------------------------------------------------------------------
#
# Probe Initialization File
#
# This is the initialization file for the ProbeSvr process. 
#
# ------------------------------------------------------------------------

# ------------------------------------------------------------------------
# General probe parameters
# ------------------------------------------------------------------------

[General]

# Specify the local host to which the ProbeSvr server socket should bind,
# or leave blank to bind the socket without specifying a local host.
#LocalHost=127.0.0.1

# Specify the LogMsg queue for text-based variable change logging, 
# or leave blank to disable text-based change logging.
TextChangeLog=LogMsg

# Specify the LogMsg queue for binary variable change logging,
# or leave blank to disable binary change logging.
BinaryChangeLog=ProbeLog

# Specify the default timeout for sending a message to a client (ms)
SendTimeout=5000

# ------------------------------------------------------------------------
# Define custom Probe Sources
# ------------------------------------------------------------------------

[ProbeSource]
#SourceName   #DLL file path
QACRS         %TSENTRY_SYSDIR%\%TSENTRY_SYSNAME%\bin\QacrsSvr.dll

The GsmOpcSvr task is an OPC (OLE for Process Control) server for Tsentry global shared memory.  It accepts requests for named variables in global common from an OPC client and returns the current value of that variable to the client.  As the value in global common changes, the server continues to push updates out to the client.  The server also allows clients to write the values of these variables back into global common.

TrendMgr

The TrendMgr task is the manager process for the trending subsystem.

TrendGsm

The TrendGsm task is responsible for trending data from global shared memory.

TrendSrv

The TrendSrv task is the server process for delivering trended data to trend clients across the network.

TrendTrig

The TrendTrig task is the main process for the historical trending subsystem.

GsmExpSvr

The GsmExpSvr task [LINK] is the server portion of the software-based reflective memory subsystem, discussed in the Data Transfer section.

GsmExpRcv

The GsmExpRcv task [LINK] is the client portion of the software-based reflective memory subsystem, discussed in the Data Transfer section.

GsmPifBld

The GsmPifBld process [LINK] is responsible for building the data dictionary program information files before starting the Tsentry system, discussed in detail in the Data Dictionary section.

VarIniChk is a stand-alone utilty program that lists the diferences between the variables defined in the data dictionary and those described by entries in the variable.ini file.  The program produces 3 lists of variables:

1. The scalar variables not defined in variable.ini.

2. Array variables not defined in variable.ini.

3. Structures and non-std variables defnitions that must not be in variable.ini.

This program is run from a dos command prompt, as follows:

%TSENTRY_SYSDIR%\tprintrt\bin\VarIniChk   sysStruct.ini  sysVars.ini   VarIniChk.log

Where:

sysStruct.ini is the fully qualified data dictionary structure file name
If not specified, the default file name is:
%TSENTRY_SYSDIR%\%TSENTRY_SYSNAME%\Pif\%TSENTRY_SYSNAME%Struct.ini
	
sysVars.ini is the fully qualified data dictionary variable definition file name
If not specified, the default file name is:
%TSENTRY_SYSDIR%\%TSENTRY_SYSNAME%\Pif\%TSENTRY_SYSNAME%Vars.ini
	
VarIniChk.log is the fully qualified output log file name
If not specified, the default file name is:
%TSENTRY_SYSDIR%\%TSENTRY_SYSNAME%\Logs\VarIniChk.log

VarIniSort is a stand-alone utilty program that reads data from a 'source' Tsentry variable.ini file, sorts the contents of the lines in the [VarDef] section by variable name, and writes out the updated contents to a 'destination' file.

This program is run from a dos command prompt.

Program command line calling format:

            VarIniSort     sysVars.ini      sysVars.ini.new

The command line may have one or two parameters:

The first parameter is the fully qualified name of the source (input) Tsentry variable.ini file.

The second parameter is the fully qualified name of the destination (output) Tsentry variable.ini file.

If no second parameter is found, the source file name will be used as the destination file name.

File definitions may use environment variables in the file names.

Program Return value:

      0 = No Error

      1 = illegal Source file name

      2 = illegal Target file name

      3 = illegal Source file - no [VarDef] section

      4 = No Source Name

Notes:

1. There will be the same number of lines (records) in the output as were found in the input file.

2. Blank lines and comment lines starting with a '#' are sorted to the top of the [VarDef] section.

3. Variable names start in column 1 and are sorted in ascending alpha order.

4. Array variables with no indices "[]" are sorted prior to the same variable with numeric indices "[12]".

5. Array variables with numeric indicies are sorted in numeric order.

6. Max number of variables that can successfully be sorted is set by define MAXVARS currently set equal to 10000.

7. Variable names that do not have the same number of open brackets ‘]’ as they do closing brackets ‘[‘ are changed to #ERROR#(original line) in the [VarDef] section.

8. The number of lines sorted, the number of errors, and the status are displayed to the user.

The tpriNtRtAdmin application is used offline for creating new systems, tasks, and screens. You can find the application at: D:\locNtRt\tpriNtRt\Apps\tpriNtRtAdmin\tpriNtRtAdmin.exe.

The first time tpriNtRtAdmin is started, it will look like this:

The tpriNtRtAdmin application uses a configuration file to save and retrieve information.  This file can be found at %SYSTEMROOT%\system32\tpriNtRtAdmin.ini.  If this file does not exist the first time you run tpriNtRtAdmin, one will be automatically created.  Consequently, you need to be running as a user that has enough privileges to write to this file.  On Windows 2000, at least Power User level is required.

Before tasks and screens can be created a new system must be generated. Start up tpriNtRtAdmin and then perform the following actions:

1. Enter SystemID and System Name, e.g. ‘Demo’ and ‘Demo Development System’

2. Click ‘Generate New System’

3. A list of steps for creating the demo system is displayed; those items that are checked have been automatically finished, those that are unchecked must be performed manually.

   If this is the first time you are configuring a system on your machine, you need to manually do each of the steps following. If you have already configured a system previously, then only building the data dictionary is necessary

   1. Configure DCOM as required by your system, either Windows 2000 [LINK] or XP/2003 [LINK].

   2. Configure Internet Explorer [LINK] as required by your system.  Note that depending on your system you may not need to perform all items.

   3. Verify wwwroot virtual directories (My Computer | Manage | Services and Applications | Internet Information Services | Default Web Site | Tsentry)

   4. Open the main Tsentry menu (http://127.0.0.1/Tsentry), click on the HMI Setup link, and follow all instructions on this screen.  Once this is complete, you can return to the main menu to try any of the standard Tsentry screens (Probe, TrendX, etc.)

   5. Customize Data Dictionary TsentryHelp | (Data Dictionary) - use the created Visual Studio solution in the D:\locNtRt\sys\Tasks directory and 'Build | Batch Build | Check DemoDataDictionary | Rebuild'.

Once a system has been created, you may create new tasks.  Task generation results in creating three new files: a project file (newtask.dsp), a source file (newtask.cpp), and a header file (newtask.h).  By default, all of these files are put into a new directory with the same name as the new task. For example, if you have created a system ID called DemoSys and a new task called mytask, then the new files would be:

            D:\locNtRt\DemoSys\Tasks\mytask\mytask.dsp

            D:\locNtRt\DemoSys\Tasks\mytask\mytask.cpp

            D:\locNtRt\DemoSys\Tasks\mytask\mytask.h

You may wish to put these files in alternate locations, which you can do by checking the “Specify Locations” checkbox.  Note, you cannot simply move the files manually to their desired location, unless you also manually update all of the location dependencies in the file mytask.dsp (not recommended).

There is also an option to generate a task that uses managed extensions.  This flag creates a task that is compatible with the Common Language Runtime and .NET Framework libraries.  This type of task however cannot be compiled and linked as a hard real-time RTSS task.  A managed extensions task also generates a fourth source file mytaskAssemblyInfo.cpp, which provides information for the generated assembly.

If you need to add additional compiler or linker flags to the project settings, you can do so by manually editing the file: %SYSTEMROOT%\system32\tpriNtRtAdmin.ini Under the [TaskInfo] section there are 8 commented key names which you can uncomment and add your own compiler or link options.

Screens are used to display and modify values using a wide variety of visual tools. The combination of these tools yields a powerful and fully customizable real-time graphical user interface. To build a new screen, follow these steps:

1. Run tpriNtRt administrator program D:\locNtRt\tpriNtRt\Apps\tpriNtRtAdmin\tpriNtRtAdmin.exe

2. Enter Screen Name, e.g. ‘DemoScreenXX’ where ‘XX’ is a unique number (must be unique so your screen doesn’t conflict with anyone else’s screen)

3. Click ‘Generate New Screen’

4. A list of steps for creating the demo screen is displayed; those items that are checked have been automatically finished, while those that are unchecked must be performed manually.
   

For a more detailed explanation of building an HMI screen refer to the Screen Development [LINK] section.

The tpriPublisher is used to rebuild and publish HMI screens for viewing through Internet Explorer.  It supports VB.NET screens, VB.6 screens, and pure html/asp screens.

The topmost drop down box above selects the current screen group for publishing.  A screen group defines a common set of parameters to be used to build and publish all screens in that group.  All screens built in under a given screen group must be stored on disk in individual subdirectories off of the root screen directory specified for the group.

Once a screen group is selected from the drop down list, the main list box below is filled with the names of all screens found in the group.  This list is populated as followed:

• If a subdirectory contains a .vbproj file whose name matches that of the subdirectory itself, this VB.NET screen is added to the list.

• Otherwise, if a subdirectory contains a .ocx file whose name matches that of the subdirectory itself, this VB.6 screen is added to the list.

• Otherwise, if a subdirectory contains either a .htm or .asp page whose name matches that of the subdirectory itself, this pure .htm/.asp screen is added to the list.

In order to rebuild and/or publish a screen, highlight the screen name in the screen list box and push one of the buttons to the right.  The Rebuild button attempts to rebuild the screen from its source code.

• For VB.NET screens, this operation is not defined.  VB.NET screens must be rebuilt via the Visual Studio.NET environment.

• For VB.6 screens, this operation attempts to rebuild the screen using the command line tools provided with the VB.6 compiler.  

• For pure html/asp screen, this operation is not defined.

The Publish button creates all files required to view this screen in a web browser and moves these files into the web share specified for the group.

• For VB.NET screens, this operation creates a new asp/htm file (or updated the existing file) from the htm template moves it into the defined web share directory.  It also moves all required DLL files into the /bin/ subdirectory in the web share.

• For VB.6 screens, this operation creates a new asp/htm file (or updated the existing file) from the htm template and moves it into the defined web share directory.  It also creates a .cab file including the .ocx ActiveX control itself and a setup.inf file containing instructions for remote deployment and moves this .cab file into the /cab/ subdirectory in the web share.

• For pure htm/asp screens, this operation moves all files and subdirectories contained in the screen directory into the defined web share directory.  In addition, it processes all .htm and .asp files according to the htm template.

The button with two leftward pointing arrows on the right of the Rebuild and Publish buttons performs both actions on each of the highlighted screens.

For publishing a cab file containing a library of VB.6 controls included and used on multiple screens, the bottommost dropdown box can be used to select the appropriate included cab file.  Pushing the Publish button to the right of this list builds the cab file itself and updates any template files used when creating cab files for screens that must include this cab file.  Note that after publishing an included cab file, all screens that use this file must also be rebuilt and republished.

Creation of the actual web page associated with a given screen is performed as follows:

1. If a web page does not already exist in the web share directory, the htm template file is copied as the default file; otherwise, operation begins with the existing web page file.

2. The internals of this web page file are processed from the beginning as follows:

3. If an HTML tag in the form <!--NAMEDSECTION="SectionName,TemplateFile"--> is encountered, the following <!--ENDNAMEDSECTION--> tag is then also located.  The text between these two tags is then replaced with the text contained in the corresponding named section (first parameter "SectionName" above) in the specified template file (second parameter "TemplateFile" above).  In practice this template file is typically same htm template file used above.

4. If an HTML tag in the form <!--REPLACEWITHSTRING="MyKey"--> is encountered, it is replaced with the string associated with the specified key.  The defined keys are:

Screen building and publishing operations can also be executed directly from the command line using tpriPublisher.com (rather than tpriPublisher.exe).  In this case, all operation is driven by command line parameters and no GUI is presented to the user.  The calling format is as follows:

Examples:

• tpriPublisher -b -g MyGroup -a
  Build all screens in the Group MyGroup.

• tpriPublisher -b -g MyGroup -s MyScreen
  Build the screen MyScreen from the Group MyGroup.

• tpriPublisher -p -g MyGroup -s MyScreen1 -s MyScreen2
  Publish the screens MyScreen1 and MyScreen2 from the Group MyGroup.

• tpriPublisher -bp -g MyGroup1 -s MyScreen1 -p -g MyGroup2 -s MyScreen2
  Build and publish the screen MyScreen1 from the Group MyGroup1 and publish the screen MyScreen2 from the group MyGroup2.

The tpriPublisher is configured through the same ini file as the tpriNtRtAdmin task, %SYSTEMROOT%\system32\tpriNtRtAdmin.ini.  The following sections and keys pertain to the tpriPublisher task:

[BuildInfo]
This section defines general screen building and packaging parameters:

• msvb=D:\program files\microsoft visual studio\vb98\vb6.exe
  The file name and location of the standard Visual Basic executable.  This is used for automatic building of your screens and in general the only change should be setting the default installation drive of Visual Studio/Basic.

• screenInfTemplate=template\tpriScreen.inf.template
  The file name and location of the default screen setup.inf template.  This template contains default installation instructions to be packaged with an ActiveX screen in its cab file.  This parameter is only used if it is not overridden by a screenInfTemplate key specified in the group settings.

• screenHtmTemplate=template\tpriScreen.htm.template
  The file name and location of the default screen web page template.  This template is the default web page for hosting ActiveX controls.  This parameter is only used if it is not overridden by a screenHtmTemplate key specified in the group settings.

• screenExt=asp
  The default file extension for the web pages published by the tpriPublisher.  This parameter is only used if it is not overridden by a screenExt key specified in the group settings.

• cabarc=cabarc.exe
  The file name and location of the cabarc executable delivered along with the tpriPublisher.  This is only required if you are signing your cab files and in general should never change from its default value of ‘cabarc.exe’.

• signcode=D:\program files\microsoft visual studio\common\ide\ide98\signcode.exe
  The file name and location of the signcode executable, typically provided as part of Visual Studio.  This is only required if you are signing your cab files and in general the only change should be setting the default installation drive of Visual Studio.

• timestamp=http://timestamp.verisign.com/scripts/timstamp.dll
  The web address of a timestamping service.  This is only required if you are signing your cab files and in general should remain unchanged.
  

[Groups]
This section defines the names of the various screen groups available for building and publishing. Each line specifies the name of a given group:

TelePro VEG/EE

Your #1 Cold Mill 

[TelePro VEG/EE]
Each group specified in the [Groups] section must have a separate section by the same name to define parameters for building and publishing the screens contained therein.  The following keys are used to specify this configuration:

• ctrlroot=D:\tpriNtRt\veg\Screens
  Defines the parent directory containing all the screen projects.  Each individual screen is expected to be contained in an individual directory under the ctrlroot directory.  This parameter is mandatory.

• wwwroot=D:\tpriNtRt\veg\wwwroot
  Defines the destination directory for the web pages.  The VB project and output .ocx files for each screen must be contained in an individual directory under ctrlroot.  The subdirectory, .vbp, and .ocx files must all have the same name.  This parameter is mandatory.

• cabroot=D:\tpriNtRt\veg\wwwroot\cab
  Defines the destination directory for the cab files.  If this is not .\cab located in the wwwroot directory above you must define a custom tpriScreen.htm.template or the cab files will not automatically download in Internet Explorer.  If this parameter is not specified it is assumed to be as above.

• infTemplate=D:\tpriNtRt\veg\Screens\tpriPublisher\vegScreen.inf.template
  The file name and location for the setup.inf file template to be used by this screen group.  This parameter is only required if it is different from the infTemplate value set in the [BuildInfo] section of this file.

• htmTemplate=D:\tpriNtRt\veg\Screens\tpriPublisher\vegScreen.htm.template
  The file name and location for the htm file template to be used by this screen group.  This parameter is only required if it is different from the htmTemplate value set in the [BuildInfo] section of this file.

• includeCabs=yourStdControls,tpriStdControls,vs7,pe3
  A comma delimited list of the cab files to be referenced as dependencies by the cab file generated for screens in this group.  The default setting includes the tpriStdControls and the pe3 (ProEssentials graph controls).  Each cab specified in this parameter (including tpriStdControls and pe3, if the parameter is omitted), must have its own cab section as defined below.

• spc=a:\mycertificate.spc
  The file name and location for the security certificate for signing the cab file.  This parameter is only required if you are signing your screen .cab files.

• pvk=a:\myprivatekey.pvk
  The file name and location for the private key for signing the cab file.  This parameter is only required if you are signing your screen .cab files.

• info=http://www.tpri.com
  The information string attached when signing the cab file, typically a web address for further information about the control.  This parameter is only required if you are signing your screen .cab files.

• owner=TelePro
  The name of the owner of these screens.  This will be used in the title when signing the cab file.  This parameter is only required if you are signing your screen .cab files.
  

 [Cabs]

This section defines the names of the various user defined cab files available for publishing.  Each line specifies the file name of a given cab:

yourStdControls

yourSpecialControls

[tpriStdControls]

Each cab specified either in the [Cabs] section or by the includeCabs value for a group must have a section defined in the file.  The parameters specified in this group dictate how the specific cab file is to be built and/or used by other screen cabs.

• ctrlroot=D:\tpriNtRt\std\Controls\official
  Defines the directory containing all the official controls to be included in this cab file.  This parameter is only required if the tpriPublisher will be used to create this cab file – that is, if this cab is specified in the [Cabs] section above.

• cabroot=D:\tpriNtRt\std\Screens\wwwroot\cab
  Defines the destination directory for the built cab file.  This parameter is only required if the tpriPublisher will be used to create this cab file – that is, if this cab is specified in the [Cabs] section above.

• httproot=/tsentry/cab
  Defines the http path to be given when referencing other cab files to this one.  It is the relative path from Internet Explorer’s point of view where this cab file can be found.

• infTemplate=template\tpriStdControls.inf.template
  The file name and location of the inf template to be used in creating this cab file.  This also implicitly defines the names and locations of the metafiles used for making this cab file a dependency of another cab file.  The names of these metafiles given the above key value would be ‘template\tpriStdControls.installFiles.template’ and ‘template\tpriStdControls.installSections.template’.

• spc=a:\mycertificate.spc
  The file name and location for the security certificate for signing the cab file.  This parameter is only required if you are signing your screen .cab files.

• pvk=a:\myprivatekey.pvk
  The file name and location for the private key for signing the cab file.  This parameter is only required if you are signing your screen .cab files.

• info=http://www.tpri.com
  The information string attached when signing the cab file, typically a web address for further information about the control.  This parameter is only required if you are signing your screen .cab files.

• owner=TelePro
  The name of the owner of these screens.  This will be used in the title when signing the cab file.  This parameter is only required if you are signing your screen .cab files.
  

A sample tpriNtRtAdmin.ini file for the tpriPublisher is provided below:

[BuildInfo]
cabarc=cabarc.exe
signcode=D:\program files\microsoft visual studio\common\ide\ide98\signcode.exe
timestamp=http://timestamp.verisign.com/scripts/timstamp.dll
msvb=D:\program files\microsoft visual studio\vb98\vb6.exe
screenInfTemplate=template\tpriScreen.inf.template
screenHtmTemplate=template\tpriScreen.htm.template
screenExt=asp

[Groups]
TelePro Standard Screens
TelePro VEG/EE

[TelePro Standard Screens]
ctrlroot=D:\tpriNtRt\std\Screens
wwwroot=D:\tpriNtRt\std\Screens\wwwroot
cabroot=D:\tpriNtRt\std\Screens\wwwroot\cab
spc=a:\verisign.spc
pvk=a:\verisign.pvk
info=http://www.tpri.com
title=TelePro
includeCabs=tpriStdControls,pe3

[TelePro VEG/EE]
ctrlroot=D:\tpriNtRt\veg\Screens
wwwroot=D:\tpriNtRt\veg\wwwroot
cabroot=D:\tpriNtRt\veg\wwwroot\cab
spc=a:\verisign.spc
pvk=a:\verisign.pvk
info=http://www.tpri.com
owner=TelePro

[Cabs]

[tpriStdControls]
infTemplate=template\tpriStdControls.inf.template

[pe3]
infTemplate=template\pe3.inf.template