7.29. Running multiple client instances simultaneously

After a standard installation of the IDERI note client, a single instance of the client is configured to run on the user’s desktop. This single client instance will try to connect to a single IDERI note server and - in tandem with its associated ticker instance - will only show messages that originate from the server that it is connected to. However, some organizations have deployed multiple IDERI note servers and hence need to run multiple clients that each connect to a different IDERI note server on some users’ desktops. The following paragraphs will outline how to configure a client computer in such a way that it is capable of starting the client in different configurations simultaneously for that purpose.

7.29.1. How the default client instance is started

After installation, the client (inotecln.exe) will run with the default instance, i.e. the connection settings that have been supplied at installation time. This encompasses the IDERI note server name or the method to find it, the protocol to use (TCP or named pipes), an optional port number and much more. All these settings ultimately result in a command line as documented in section 9.1 that is eventually passed to the client. The command line setting for the default client configuration can be found in the “DefaultCommandLine” REG_SZ registry value under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\ideri\inotecln. However, in order for inotecln.exe to be started with the command line supplied with the “DefaultCommandLine” registry value, some other process must read this value and start inotecln.exe at some point. It is clientlaunch.exe that does this. The default settings after installation of the client will add the invocation of clientlaunch.exe into the “ideriClient” REG_SZ value in the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run (see section 2.1), so clientlaunch.exe will be launched by explorer.exe that acts as the user shell in Windows after login. But clientlaunch.exe is not only responsible for launching the default client instance, it also acts as the central hub for launching additional client instances if configured appropriately. This is what the remainder of this chapter is all about.

7.29.2. Starting secondary client instances from within clientlaunch.exe

Secondary clients are configured using the following registry key:


For the remainder of this section, this subkey will be referred to as the “secondary clients registry key”. This key does not exist after a standard installation and thus must be created manually or via a client management product. Since this key is not created by the IDERI note client installer, the uninstall process will also not delete it during uninstall. This also means, that this key will not be touched when updating the IDERI note client to a new version, where an uninstallation of the previous version is by nature a necessary part of the overall update process. So any settings made under this key will survive a client update. For each instance of a secondary client, a separate subkey under this key must be devised. The name of the subkey is unimportant to a certain extent, but it must contain the registry values in table Registry Values for secondary Clients in order for the client to be started successfully:

Registry Values for secondary Clients
Value name Value Type Explanation
Server REG_SZ The name of the IDERI note server.
HistoryMenuItem (optional) REG_SZ The menu item string to appear in the client context menu for the connection’s history application (optional).
PollingInterval REG_DWORD The client polling interval in ms.
TCP REG_DWORD If this value is non-zero, the client connects via a dedicated TCP port to its server, otherwise named pipes are used.
Port REG_DWORD The TCP port number to be used for the client connection if TCP is used as the connection protocol.

However, this does not mean that a secondary client instance gets started automatically by clientlaunch.exe with these registry values configured correctly. In order for the secondary client to be started, its subkey name (with the values from table Registry Values for secondary Clients in it) must be enabled first. This is done via the REG_MULTI_SZ value “ClientsToStart” in the secondary clients registry key. Only if this multi-string value contains the name of the subkey under the secondary clients registry key, the client launch parameters from table Registry Values for secondary Clients will be evaluated by clientlaunch.exe and the secondary client will be started.

7.29.3. Access secondary clients from the IDERI note client’s context menu

In standard configuration, the IDERI note client shows an icon in the system notification area that shows a context menu when clicked with the secondary mouse button (right mouse button click). Using this context menu, the user can invoke the history application, enter “Do-Not-Disturb-Mode” or show or hide the ticker and much more. If multiple clients are configured, each one of them would create its own icon in the system notification area. This is prevented by the “OnlyOneTrayIcon” registry value (see section 10.1) and its counterpart at installation time, the “ONLYONETRAYICON” MSI property (see section 8.3), which are both set to 1 by default. With default settings, only the default client that is started with the command line found in the “DefaultCommandLine” registry value will create a tray icon and will control the other client instances to some extent. As a result, entering “Do-Not-Disturb-Mode”, exiting the clients, showing or hiding the tickers will work from the single default client context menu for all simultaneous client instances at the same time. However, in order for the client history application to be invoked from the single default client context menu, some configuration has to be performed, again using the secondary clients registry key: The REG_MULTI_SZ value “ClientHistoryMenuOrder” in the secondary clients registry key specifies a similar list of clients, much like the “ClientsToStart” value. Again, each item in this list denotes one of the secondary clients subkeys with client information, but this time, the list described by this value is the order of the history menu items as they appear in the client context menu. The maximum number of history context menu items that can be specified this way is 10. The actual text that appears in the context menu for the history item must be specified in the individual secondary clients subkeys using the REG_SZ value “HistoryMenuItem” (see table Registry Values for secondary Clients).

Notice that specifying connection configuration via an Active Directory Lookup for a service connection point as outlined in section 12.2 is not supported for secondary clients. This makes sense since there can only be at most one client looking up unique connection parameters - all subsequent clients would look up the exact same connection parameters. Conversely, this means that the default client as specified via the “DefaultCommandLine” registry value, is the only client that can be configured for a service connection point lookup.


Message appearance order when running multiple clients

One of the key product features of IDERI note is the division of message importance into the three classes information, warning and alert with each class configurable for specific behavior. Part of this division is the order in which messages appear on the user’s desktop when multiple messages are due at the same time. The IDERI note client strictly guarantees that alert windows will always be displayed prior to warning messages, which in turn will always appear before information messages. Unfortunately this strict order of messages ordered by their appearance cannot be kept when running multiple clients. This is because each client instance works independently from the others. So if one client has no alerts to show but only an information message, this information message will appear while at the same time an alert message from another client, connected to a different server might be shown. With a single client there is a guarantee that the user will be presented at most one message at a time. With multiple clients, each client instance will show its messages independently from the other client instances, so there will be at most as many message windows visible on the user’s deskop as there are client instances. A similar situation exists with the ticker shown for the client instances: Each client instance will spawn its own ticker, so it is necessary for users to arrange tickers in a way that they are docked to their own screen edge.