Author: Damien Fuzeau

• Product Owner •Damien Fuzeau has joined the 4D Product team in February 2019. As a Product Owner, he is in charge of writing user stories, then translating them to functional specifications. His job also entails making sure that the feature implementations delivered are meeting the customer needs.Damien is graduated from the University of Nantes in software engineering. He spent more than 23 years in its former company, first as developer (discovering 4D in 1997), and later as engineering manager and software architect. This company is a 4D OEM partner and deployed 4D based business softwares for thousands users, on hundreds servers. So, Damien is used to 4D development and deployment in a multi-language context.
Product blank

Multiple web servers in a single 4D instance

Have you ever needed to use multiple web servers in order to, for example, split your web application code into several business units, or separate the administrator’s web server from the user’s or run an old part, not preemptive-ready yet, in a separate instance, allowing the main part to run preemptive?

If you’re nodding your head yes, then keep reading because 4D v18 R3 allows you to do so … with ease.

Product blank

Take control of your work area

Want to adapt your application’s interface to your end user’s system preferences? Want to make sure your application’s interface isn’t obscured by the macOS dock or menu, or by the Windows taskbar? In this blog post, we’ll show you how!

Product blank

Build a custom remote connection dialog

Do you need to build a customized 4D connection dialog? Interested in connecting your client application to different servers? These are two scenarios that 4D v18 lets you to handle. This blog post is for you if you want to create a custom remote connection dialog and connect it to merged 4D servers. Keep reading!

Product blank

Deployment made easy with 4D v18

4D v18 introduces a new architecture for files and folders to keep your deployed macOS package and Windows application folders intact. In a nutshell, the logs folder and all user-based settings, including 4D backup settings, are now stored next to the data file. In fact, the settings exist twice; one next to the structure to use as default settings for new data files, and one beside the data file, storing user changes.
As a result, the folder containing the structure can be read-only, since nothing is modified inside (*). Deployment becomes easier because the structure folder can simply be replaced, nothing within it needs to be copied beforehand.

(*) only in project databases. In binary databases the user & password tables are stored in the structure, so the folder must not be read-only.