Version 1.0 of TurboPlayerService does not make use of DigaSystem registry / parameters files or of DPE parameter service. Instead there is only a single configuration file: TurboPlayerService.par. This is a simple XML file. You can open the file with a text editor and you will see that there is an explanation for each parameter.

The connection parameters are very important. They specify the way used by the service to communicate with TurboPlayer. We recommend to use IP (see next paragraph). On the TurboPlayer side you should check the parameters ( DigaSystem registry: TurboPlayer \ Communication \ TreeManager \ PortsForGUIs and TurboPlayer \ Communication \ RundownKernel\PortsForGUIs ) whether enough ports are being opened in order to serve multiple GUIs. The two parameters are used even if no IP is used. They simply define how many GUIs can connect.

If you want to use memory-mapped files (MMF) for communication, there is a special problem. If one part of the communication - here TurboPlayerService - runs as a Windows service, the MMF must be created in the global Windows namespace. This is necessary because the name of a MM file will only be visible within the same ring, meaning: a desktop file (in ring 3) will not be visible for the service (in ring 0) and vice versa. The ugly part of using the global namespace is: if you activate it, a desktop program will need a special right to create a file in the global namespace. According to Microsoft the local group policy right "Create global objects" needs to be granted to the account running the desktop progam. We have noticed that this right has no effect. It is necessary to start the program with "run as administrator". Therefore, we recommend to use IP for the communication if you have such a setup. If you really want to use MMF please set the DigaSystem registry parameter TurboPlayer \ Communication \ GlobalNamespaceForMMF to TRUE and the parameter “UseGlobalNamespaceForMMF” in the parameter file of TurboPlayerService to “True”.

Each new full-access client which connects to TurboPlayerService will generate a new connect from the service to TurboPlayer engine. This means that each individual GUI – might it be a standard or a web GUI – is known to the engine. The differentiating factor is the GUI number, which therefore must be unique for each GUI. For the standard GUI you can configure in the settings which number is used. All GUI numbers which should be available to web GUIs must be listed in the parameter “GuiNumbersRange” and all numbers listed here must be included in the “PortsForGUIs” parameter of kernel and TreeManager.

In addition there can be read-only clients. Multiple read-only clients can use the same GUI number. There is no fix limitation in the number of these clients, it is only limited by the power of the computer how many clients can be handled. In the parameter file of the service you can list all GUI numbers which should belong to read-only clients. If you do not have the license dll (see above) all connections will automatically be read-only connections.

An example:

TurboPlayer\Communication\RundownKernel\
PortsForGUIs=9981-9989

This opens 9 ports (and message boxes) to be usable by GUIs. GUI 1 could be the one of the same executable, GUI 2 could be an additional standard GUI and GUI 3 – GUI 9 could be web GUIs.

TurboPlayer\Communication\TreeManager\
PortsForGUIs=9991-9999

TurboPlayer\Communication\
FullAccessForGUIs=1,2,3,4,5,6,7

This parameter should be the contrary fof the “ReadOnlyGuiNumbers” below. Here you should list all GUI numbers with full access.

TurboPlayerService.par\
GuiNumbersRange=3,4,5,6,7,8,9

GUI numbers which are available for web GUIs which connect to the service.

TurboPlayerService.par\
ReadOnlyGuiNumbers=8,9

GUI numbers which belong to connections which do not have any write/modify access.