Discover new deployment options of 4D v18

Originally published at:

4D v18 offers many new possibilities for application deployment…


Very useful information!

Before watching the demo, I was under the wrong impression that we had to build a single user engined application to implement a custom login dialog. The presentation makes it clear that the “connection application” is just a complied application (4DZ/C with Resources and Components) not a full merged single user executable, which makes more sense.

The idea to deploy the “connection application” as a component is really cool! The custom login dialog can be invoked not only at startup but also at any time, to switch to a different server. I wonder if it can be applied to implement a synchronised mirror server system (not master-slave, but as equal partners).

The example uses an HTTP keep-alive server list, which is smart, but I wonder what are the pros can cons of using the built-in UDP broadcast system. One obvious downside is that scanning for all port numbers will be expensive, but if there is specific range of ports, maybe that would work too… For a Mac only installation, I am thinking of using Bonjour to discover running servers in the network.

As explained in the presentation, the reorganisation of backup settings is a major change in v18.

4D automatically renames the file, but it didn’t occur to me at first that the Preferences4D/Backup/ node no longer has a DataBase element. The information now belongs to backupHistory.json. If you have a customer parser, you might want to watch out for that change.

The speaker gives the practical advice to stop using hard-coded paths and switch to File and Folder (around 33:10), since settings and logs have new locations. This was also an important lesson for me.

From this presentation I made a TODO list of things to check after moving to v18:

Binary or Project

  • Must (low impact, high return)

    • Create a non-administrator, non-Designer user for Runtime Explorer access
    • Add call chain (as well as timestamp, error, error line, error method, error formula) to error logging
    • Refactor hard coded path of log and setting locations
  • Should (recommended)

    • Activate user settings, if not done already
    • Put data in a folder different from structure (even during development)
    • Put production backup settings next to data file
  • May (optional)

    • Map internal 4D users names to customer user names with user aliases
    • Add constant to Current user where internal 4D user name is needed


  • Should (recommended)

    • Put production directory.json next to data file
    • Put default directory.json next to structure file
    • Add directory.json to single user built apps explicitly, if non-designer users are needed

I’ve published a “server list” project inspired by this project.


Hi Keisuke,

Thank you for your report.

The HTTP keep-alive server list was a choice for the demo. But actually, you can imagine all server directory systems you want!

I think your TODO list is very useful and should inspire many developers, especially those deploying production applications.

Best regards,