Up until now the form designer in Quartex Pascal focused purely on visual controls. But as the IDE matures -more and more features common to RAD development is surfacing. Non visual components is finally supported by the IDE and package manager!
Non-Visual Components
In traditional development systems such as Delphi, C++Builder or Visual Studio -non visual components is a species of classes that the form designer can manage and visually represent. Technically it is the same as creating a class by code, but being able to drag & drop such objects side by side with visual controls, makes them infinitely useful.
Typical non-visual components are things like database connections, table or field bindings, image lists, event producers and config options. In most scenarios these non-visual objects are connected to a visual control through property assignments.
Same methodology
From the viewpoint of the IDE a non-visual component is the exact same as a visual control. It is registered and handled by the same internal mechanisms, and likewise created and destroyed alongside it’s visual siblings. The only difference is that they inherit from TQTXComponent rather than the DOM specific TQTXWidget.

This also means that TQTXComponent does not manage the life-cycle of a HTML5 element. There is no Handle property that reference any elements in the DOM or the NodeJS runtimes (unless the component is written that way).
You likewise use a non-visual control in the same way you would a visual one. You drag & drop the component on a form, change it’s properties using the property inspector – and that’s all there is to it.
Datamodules
The next task is to introduce datamodules. You can think of datamodules as a non-visual form. Much like TQTXComponent a datamodule does not manage any visual elements, it is purely a construct for organizing non-visual components.
In large applications with many forms where you want to share resources, such as images or a database connection – it is common to isolate these components on a global scope datamodule. Instead of each form having it’s own copy of said components, they all share one instance via a datamodule.
Perfect for NodeJS or Deno
Datamodules will revolutionize building Nodejs applications. This really is the missing link for RAD (rapid application development) server-side application building.
You will be able to drag & drop server components, database connections, communication protocols – and setup a complex server infrastructure in no time. Non-visual components and datamodules reduces tedious scaffolding to minutes rather than hours or days.
This is exactly why Delphi is so popular for building desktop applications.
Ragnarok communication protocols
With non-visual components under wraps, it will be possible for us to isolate different communication protocols as self-contained entities that you can drag & drop. So anyone can design a message protocol and emit it as a reusable component.

Imagine dropping a Websocket server on a datamodule, then dropping a ready-to-use filesystem protocol component, then an identity protocol component, and finally a chat-room protocol components. Once the protocols are attached to the server object -the server will instantly support the message-types these protocols export. Each protocol can contain hundreds of messages.
We can also isolate the wealth of Nodejs modules as drag & drop components. Features that would otherwise require time consuming manual work.
Update
A new build will be available shortly! We are hoping to have the update out this weekend with support for non-visual components. It will take some time before we can offer a rich palette with ready to rock objects, but knowing our community I dont think it will take too long before they appear in the wild 😉