[badsectoracula]

IMO there are two main reasons nowadays to check codegear's IDEs: you either have some huge Delphi codebase that you can't move anywhere else or you want C++ support with a full RAD IDE (i do not think there is anything as RAD-y as C++ Builder). QtCreator is a workable alternative though.

Well, there is a third reason, you want to have some company to blame (and ask help from) when things break :-P

[akkartik]

RAD, now there's a term I haven't heard in 10 years. Can you unpack how one modern compiled language can be more RAD than another? I thought it just meant having an IDE.

[signaru]

In the context here, it is about rapidly making a GUI by visually editing widgets, usually via drag and drop, pretty much like placing shapes in a power point slide. The IDE doesn't just contain a source code editor, but also that visual window/form "designer" (in Visual Studio jargon). The RAD IDE generates the GUI code from what you've drawn, instead of you having to manually type it yourself, hence the "Rapid" part. To attach code to an event (i.e. click) you often simply have to double click on the corresponding widget/control in the visual designer, or use the corresponding "Event" GUI element somewhere in the IDE. This was in contrast to how it was done with C++ options such as MFC prior to Visual Basic / Delphi.

It gets GUI layouts done fast, but I also think it has some drawbacks. Manually drawing controls, i.e. sizing & positioning, eventually becomes a tedious chore once you have a lot of them or if you anticipate frequent updates in the UI. One trick I always end up using is just using some simple math to do the layout as the form resizes. In C# + Winforms, I'd go further by bypassing the visual designer as much as I can and just manually spawn the widgets just like any other object. Other UI frameworks also assist in layouts or just don't make this a problem to begin with. For example WxWidgets, Qt and, if I'm right Ultimate++, have sizer/container controls that do the layout logic.

[badsectoracula]

Note that in Lazarus / Delphi things aren't exactly like that: while the IDE does generate some code, it is largely declarations for the object instances and event handles. There is no code generated for building the GUI itself, instead the framework uses language features like the RTTI and metaclasses to implement object serialization and the IDE is modifying live instances. Check my sibling comment to yours for more details.

Also note that Lazarus has way more layout functionality than what you'd see in, e.g. WinForms (in fact IIRC WinForms is even more limited than the version of Delphi that existed around its introduction). In addition to a simple "Align" property (which existed in Delphi and also has something similar in WinForms) that allows placing components at the edges and/or center area of a container (which already allows you to do a lot of layouts, e.g. many "vbox"-like layouts in other toolkits can be done in Lazarus/Delphi by setting the Align property to "alTop" or "alBottom" in all of the container's children - similar with "hbox"-like layouts by using "alLeft" or "alRight") it also has an "anchor" functionality that allows either anchoring the edges of control in place (so that, e.g., if you resize a form and you have a button anchored to the left and right sides, it will be resized horizontally) or specifying how controls relate to each other via their edges. This allows you to do things like having one button have its right edge anchored 10 pixels from to the form's right edge, its left edge not being anchored anywhere, a listbox's right edge anchored 5 pixels from the button's left edge and a bunch of other buttons having their left and right edges anchored to the left and right edges of the first button while their top edges are anchored to one of the other buttons so they form a stack. Almost all controls have an "AutoSize" property which allows them to resize themselves automatically (often to fit their contents - or, for containers, their children), which essentially means that you get automatic layout that works when forms are resized and regardless of font sizes, etc. When anchors are not enough, all containers have a ChildSizing property which allows you to specify some simple automatic layouts for children, like using row-major or column-major ordering, having them use the exact same width and/or height, etc. Finally if none of these are enough, there are some other layout-related controls like a splitter (which automatically adjusts the width of controls laid out via the Align property), pairsplitter (which provides a container with a splitter in case Align isn't enough), flow panel (which lays out children in various ways like, left to right, right to left, top to bottom, bottom to top, etc with wrapping based on rules you set for each child), scroll box (which is basically a container with automatic scrollbars when the contents do not fit), etc.

Also note that all the above are done visually without any code, though of course you can also write code if you want. It is just that it is way more rare to need to do that, especially when compared to WinForms or (worse) classic VB.

Personally whenever i make a GUI in Lazarus i place the controls manually approximating how i want the layout to be and then open the anchor editor and start assigning relations. This is enough for 99% of the layouts.

[badsectoracula]

Part of what signaru described but in Lazarus/FPC (and Delphi) it actually generalizes more - it isn't just the GUI that you can edit visually in the IDE and you aren't just editing some sort of visual stand-in/proxy: instead what the IDE edits is "live" object instances, there is support for properties at the language level as well as enough RTTI and metaclass functionality to be able to reflect an object's making and state at runtime, which allows for things like object serialization and editing said live object instances via property editors. In Lazarus (and Delphi) programs are made up of "components" (which are just subclasses of the TComponent class) and these components lie inside "packages" which are basically libraries - the same libraries your program will use - that are linked against the IDE. The libraries register the classes with the framework and the IDE (which is written against its own framework) queries the registered classes and can use them in the visual designers: when you place a component on a form you are creating an instance of a registered component class, the properties of that instance show up in the object inspector allowing you to edit them in place. When you save the form, the objects in it are serialized to the form file.

This is how the GUI editing works, but there is more to that since components do not have to be visual elements. For example check this screenshot[0], this shows some components from a package i have written that i use across various tools (mainly 3D related). The edited form (which btw is a component itself) has a visual component that represents a 3D viewport (the big black box) and four non-visual components, a component that represents a fragment/vertex shader pair for OpenGL, a component that provides undo/redo management, a component that represents a manager for all viewports and a component that can be used to render multiple viewports at the same time. The first component (the shader pair one) has its properties shown in the object inspector at the left with a "strings" editor opened for editing the FragmentCode property (which is a collection of strings meant to represent lines in an editor) and shows some GLSL code. The undo manager has its own properties and two of them are "UndoAction" and "RedoAction", meant to be assigned to "TAction" instances that will be automatically updated whenever undo events are handled. TAction is a non-visual component provided by Lazarus itself that can be used to represent GUI actions that can be invoked via various places (e.g. menu items, toolbar buttons or programmatically) so that instead of writing code against menu items, buttons, etc directly you write the code against the action and then associate the action with the menus, buttons, etc you want.

Another thing to note is that so far i mentioned GUIs but Lazarus (and Delphi) is not limited to that. As i wrote above a form (window) itself is also a component but there are also non-visual "toplevel" components too: data modules. These can contain only non-visual components (and you can even use them in non-GUI applications, e.g. command line applications or web applications). Some are used to "RAD" only meaning GUI editors and might find that weird, but if you take all of the above in consideration, it becomes obvious that since you can edit non-visual objects in a form via the IDE you may also want to be able to edit only non-visual objects in a non-visual container (which also allows making programs without a GUI while still being able to edit objects visually via the IDE).

In fact one may use the aforementioned actions but placing them inside a data module instead of a form, thus separating the logic of the program from its GUI while still being able to take advantage of the IDE's visual editing functionality.

In a way it is similar to how some game engines like, e.g. Unreal Engine, work (though UE needs a preprocessor to generate the class information while Lazarus/Delphi use language features) and is probably among the closest you can get to a Smalltalk-like environment without being able to serialize the entire environment to disk and instead working on a traditional "edit, build, run" cycle with clearly separated "editing" and "running" states.

[0] https://i.imgur.com/Yw1tTcD.png

[sakesun]

I think codegears is not their company name for several years now.

[badsectoracula]

Yeah, nowadays it is owned by Idera, though AFAIK Embarcadero bought the entire CodeGear division from Borland and then Idera bought Embarcadero.

[7thaccount]

Embarcadero right?