Commands, constants, tables and fields are stored with their tokens in the project source code files (4dm files). This allows 4D to rename them automatically. But sometimes, you would like these source code files to be stored without tokens for a better readability with a version control system or an external code editor, or for better code sharing between projects. Let’s see how to make 4D store source code without these tokens.
Default End Of Line character and Byte Order Mark usage in text files have been modified in 4D v19 R2. With 4D v19 R3, 4D extends this behavior to XML files. Let’s see how.
For many years, 4D has allowed you to develop binary databases as part of a team with a 4D Server. This way of developing is straightforward, but many developers asked us to be more efficient on source code management to deliver better traceability. 4D has heard them and developed Project mode to fit this need. This mode opened a new era of collaboration thanks to version control systems!
Project mode allows you to easily track changes with Git, the most popular version control system. But often, you don’t want to track all the files of your project in the Git repository. 4D now offers you the possibility to define what not to track in your new projects.
In a previous blog post, we showed you that documentation for methods has returned in the Explorer. Want to take things even further and use them as documentation for your components? In this blog post, we’ll show you how!
Sharing the source code of 4D components lets you customize them and make them your own! With project databases and the ability to share an application’s source code via a source control system, we’ve converted our 4D internal components into project databases and pushed the source code to the 4D GitHub account. It’s open to everyone, all you need to take advantage of it is an account on Github. Why did we do this? To make your life easier by keeping track of changes and modifications to both code and forms.
In a previous blog post, we introduced you to Git (a version control system) and Github (a cloud-based hosting service) and how you can share your 4D code with other developers. In this blog post, we’ll go a bit further by exploring some scenarios a developer may encounter, such as cloning a remote repository, ignoring already committed files, and solving merge conflicts.
The Form Editor allows you to create, modify, and customize your forms. Several tools are available to make your work easier, one of which is the Views palette. This tool makes it easy to build complex forms by distributing objects into different views. The views enable objects to be hidden or displayed as needed.
What if you’re working on a form developed by someone else? How can you quickly determine if the form uses views? Are there limitations on the number of views permitted? 4D v18 R2 and project databases eliminate these existential questions while greatly enhancing the user experience!
With the introduction of project databases, we’ve also modified the interface of some 4D dialogs. In this blog post, we’ll present some of the changes we’ve made to the form editor.
As you know, 4D now supports two ways to work with sources: binary and project databases. Binary databases are the 4D we all know and love, with source code in a binary file to allow team development with 4D Server, and all of the design elements (methods, forms, structure, etc.) gathered in a single, compact binary file, the “.4db” file. Project databases make it easier for distributed teams to work collaboratively by storing the source code in a source control system in separate, plain text files. Projects will not replace the 4DB, we have no plans to make the 4DB disappear. It’s about two different ways of working and developing. It’s up to you to choose what best suits your needs. Here’s a blog post to help you decide: