Developing and debugging server code in project applications has become easier than ever in 4D v18 R4. Without further ado, let’s take a look at how to do it.
Projects were introduced in 4D v17 R5. An architecture representing a giant evolution for 4D applications, projects opened the 4D world to source control tools, collaborative programming, code sharing, modularity, and much more! To make things even better (and simpler), 4D v18 R4 creates new projects by default, while developers – if they choose to do so – can continue to create binary databases via a simple setting.
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!
When developing an application, it can be very useful to have quick access to the details of a method (e.g., an explanation of what it does, its syntax, and a definition of the parameters passed to it). This becomes even more important when using a compiled component. You can’t look at the content of the method, so you can only rely on its documentation to understand how to use it.
The Explorer’s dialog has been enhanced and documentation is now available in 4D v18 R3 for project databases.
In a previous R-release, we added two new automatic themes to define font and the font size, so there are three automatic themes at your disposal which respect the guidelines of each platform. To design your interface, the automatic theme is the recommended way to go with each form object using the font and size recommended by the OS.
In some cases, you may need more control and have valid reasons to ignore the guidelines. With 4D v18 R3, you can override the size of the automatic themes and have more control over how your text is displayed.
In a previous blog post, we introduced a very important concept in object-oriented programming: Classes. Now we’ll go through another core concept: Inheritance, the mechanism that allows a class to acquire the behavior of another class.
Many of you have have been asking to be able to define an object type ever since the Object type became available. Thanks to object notation, many of you dream of having object functions. Dream no more and say hello to classes in 4D v18 R3 project database! In this blog post, we’re introducing one of the most interesting concepts of object-oriented programming … along with a database example and a bonus video!
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!