When running 4D Server as a Service on Windows, it is recommended that a named account be used instead of the Local User Account that is configured by default. This is important because the Local System Account may not have the proper access required to use the application. For example, if the application needs to print then an account that has the printer configured must be used; if the application needs to access the network then an account that has access to the network must be used. In addition to these examples there is another reason why it is recommended to use a named account – dialog windows.

Dialog windows created by Runtime Errors, the ALERT command, and even the debugger can wreak havoc on a 4D Server when it is running as a Service if “Allow service to interact with desktop” is enabled. These dialogs require that the user click a button before the process proceeds. The problem is that when 4D Server is running as a Service the UI is not always accessible, which makes clicking on these dialogs extremely difficult if not impossible.

However, when 4D Server is running as a Service on Windows and the "Allow service to interact with desktop" option is disabled, these types of dialogs created by 4D on the Server are ignored and the process no longer waits for user interaction.

The actual mechansim is slightly different depending on the version of 4D used:

• v15 continues execution of the method.
• v16 aborts the method.

To take advantage of this mechanism make sure a build of 4D v15/16 greater than 215400 is used and that the Local System Account is not used (i.e. the service should be running as a named account as recommended).

If there is a deployment requirement to use the Local System Account then the only way to benefit from this mechanism is to disable the "Allow service to interact with desktop" option:


Note: this mechanism only applies to 4D's dialogs and does not apply to modal dialogs created by the developer.