Borland C++ Builder (2015)
runtimeterror.com
runtimeterror.com
My main problem with delphi: it is "too proprietary". It was a very productive IDE in the 90's or early 2000's but lost their path and never recovered.
Some new versions broke compatibility with previous version's components. There was the case where you paid a good amount of money on some proprietary components and they simply wouldn't work in the next version: you were imprisoned in an obsolete IDE. By not being multi-platform (I heard it improved lately) you could only use it with/for win32 so it lost servers, embedded, cloud and mobile. By not being open-source nobody could improve it.
Then it had to compete with "native tools". Whoever develops for windows wouldn't quit ms' tools to use it, whoever develops for mac wouldn't quit apple's tools to use it, whoever develops for android wouldn't quit google's tools to use it, whoever develops for linux was mostly ignored after kylix.
Note that I didn't even mentioned price and license.
They improved it later, I heard. But seems more like the old case of too little too late. Most successful programming languages today are open source and multi-platform. Delphi was dependent on win32 for too long and it still is "too proprietary". You do the world a favor by porting your project to lazarus.
But man are you ever right about the compatibility issues! Upgrading from Delphi 5 to the (then current) Delphi 2005 was a total nightmare. Our codebase was about 600k lines, and I will never forget the trauma of trying to get it to just build in the newer version.
The comparison with .NET codebases that "just work" from version to version is night and day, and sadly it's worth putting up with a laggy beast of an IDE to have that security around your projects.
Did anyone see it as “not native” in its native environment, Windows? Weird. It was a straight continuation of Turbo Pascal and Borland C++, both as native as anything could be since DOS and Windows 3. I think you're just plain wrong there. I don't know anyone who saw Delphi and C++ Builder as “not native”.
Other toolkits added this sort of functionality so it doesn't look as out of place nowadays, but especially icons on buttons was kind of a Borland sign.
In Win3.1 times it was even more apparent since Borland OWL had its own sort of "theme" for dialogs that had a textured and chiseled look with large 3D controls, so these apps stood out more. This was toned down in 32bit versions of OWL though it still used custom controls (check the button shape here[0] and how it looks a bit off compared to other buttons).
Also Borland had a tendency to make their own icons for stuff that other programs used standardized icons for, often with very different symbols which also made them stand out and look weird. For example in the screenshot i linked at the first two icons are for open and save and the bolt icon is for running - those are from OWL. In Delphi the save was different (but still not a floppy) and the new and open icons were identical, a shining page of paper, except the open had words on it. Their "undo" icon was a red circle with a crossed line that in other apps would be something like "delete".
Also FWIW i noticed that Neverwinter Nights' editor was made in Borland C++ Builder (i wrote the linked post) because the arrow icons used in it (visible in the screenshot in the post below the 3d viewport) are straight out of Borland C++ Builder. Though Bioware did make their own icons for other stuff.
Again, nowadays these things do not stand out much, but back in the 90s/early 2000s when the Windows world was more uniform and developers did care about making applications that had the "Win9x" look they did.
Similar to how many Delphi applications could simply not use TBitBtn (its use isn't forced) but they did use it anyway.
Yeah, but those are signs of it being not Microsoft, not "not native". At least back in those days, "native" meant "compiled into an .EXE file that runs directly on the hardware" (as opposed to, say, bytecode that runs on a VM (that is an .EXE that runs the hardware)).
To me, it still does.
The component palette was identical to Delphi (and was still Object Pascal code). You could use Delphi UI components with it.
C++ support was a bit buggy in places, but not terrible. I had worse problems compiling C++ on AIX.
Delphi and C++ Builder were simply the best native UI creation tools I've ever used.
Even since Turbo Pascal, and with Delphi, every new version (5->6->7) of a compiler/tool required new compiled libraries/components. Eventually a lot of shops (and Delphi and C++ builder were huge in xUSSR, for example) stopped to care and moved on to Java/C#.
You can't really open old projects in new versions of the software. Some devs use VMs to develop on the old versions of Builder.
The documentation and the example code for the C++ side are horrible, because they are focused on Delphi. You must know Delphi to figure out how to use the libraries in C++. The documentation for Delphi also feels very light and outdated. The latest books about it are from the begining of the 2000s and there are very few Youtube videos about it.
Sometimes Intellisense stops working and you don't know why. Sometimes some access violation happens and the debugger gives you no hint why.
The price is also expensive. I think my company spent 2300€ for a single license and they expect you to renew every year.
Community edition: https://www.embarcadero.com/products/cbuilder/starter
Professional https://www.embarcadero.com/products/cbuilder
https://www.embarcadero.com/app-development-tools-store/cbui...
If community edition is never updated, IDK how they can expect to grow or gain new customers. Thats why Visual Studio updates their community edition so often, because that helps people get familiar with the tools and companies are more likely to adopt them.
They don't. The business model is to milk existing customers for all they have got.
https://visualstudio.microsoft.com/vs/pricing/?tab=business
https://visualstudio.microsoft.com/wp-content/uploads/2020/0...
And maybe by .NET 9, all the kinds of Delphi workloads will be finally supported by Native AOT and low level coding capabilities.
All enterprise products cost an arm and a leg, and at that level it hardly matters, license costs aren't where usually project budgets get burned.
If I take look on roadmaps and apply developer velocity of MAUI, WinForms and WPF it will take many more versions.
Some minor updates since then:
Since then i also tried Qt Creator and while it feels more clunky than even the original Borland C++ Builder, especially with the form designer (which i think is basically the standardalone Qt Designer embedded in it) and how it doesn't feel like a coherent product but a mashup of different bits and pieces, it is probably the closest you can find in open source for a RAD(-ish) C++ IDE (big caveat that i have only used it sparingly, never made anything more than a few toy apps with it). I am a bit worried that you're still relying on the Qt company which has shown hostility towards the open source community several times but i think that between Embarcadero and Qt company, relying on the latter is better and it is popular enough for external developers to pick it up in case it gets abandoned (the benefit of it being FLOSS).
But at the end i still think Lazarus is better when it comes to a RAD IDE and framework (i am taking all three of these combined, not separated) for desktop applications, assuming you do not mind using Free Pascal as the language. Of course that is with my big bias since i learned programming on Turbo Pascal, used Delphi in the 90s, use Lazarus since the 2000s and in recent years even contribute to its development. Someone starting nowadays will most likely have a harder time getting used to it and the documentation could certainly be better.
You got piles of books and piles of floppy disks (later piles of CDROMs) for that.
Only recently, free development tools have become available that rival commercial offerings.
But most serious developers do not care about a few thousand dollars in tooling cost, because the main determinant of software cost is developer salaries and nothing else. Since they are typically six digit dollar amounts, the cost for tools like editors, IDEs, compilers and libraries pales in comparison or becomes a rounding error.
Delphi also had similar prices.
In comparison Microsoft's prices for Visual C++ 97 were much higher, at least according to this old post[2]. The cheapest might have been $99 like Borland's but that was for the learning edition which could only be used by students for non-commercial purposes (Borland's $99 versions of Delphi and BCB did not have that restriction) and the next cheapest was $499 - practically five times more expensive.
[0] http://web.archive.org/web/19970605053133/http://www.borland...
[1] http://web.archive.org/web/20230220010556/https://www.embarc...
[2] https://www.itprotoday.com/windows-78/microsoft-sets-pricing...
Truthfully I first dipped my toes into Windows development using Visual Basic, then jumped to MSVC++ & MFC after I quickly outgrew VB. Having smart colleagues [hi Keith!] and great MFC books [hi Mike Blaszczak!] around certainly made it easier.
What you write about sounds very much like you could solve easily changing the default behaviours. There was some "autoalign" property, or something similar, that you can disable.
I won't install a demo to check, I'm afraid, but knowing that there's a solution could help?
There are tools for automatic alignment, Lazarus has both an align property (align to the parent's left, right, top or bottom edge or to the remaining area in the center, which is good enough for many layouts) and an anchor system (allowing to either "anchor" an control's edge in place so it gets resized with the parent or to place an edge relative to another control's edge or center point) as well properties for margins, min/max size and a bunch of special-case containers that layout their children like page/flow, etc.
However the controls still have their left/top/width/height properties, the layout functionality just updates those. And since forms are just serialized objects that store a property's value if it is different from the default value, the left/top/width/height properties are always stored in the form even if they'd be overridden later by the automatic layout mechanisms (object serialization exists at a lower level than that, it doesn't "know" about forms or anything like that - in Lazarus it isn't even part of the LCL framework but instead part of Free Pascal's FCL framework on top of which LCL was written and technically these are two separate projects).
The end result is that if you open a project and for some reason the controls get resized (e.g. you have a different theme than the last time you opened it which would cause some buttons to be smaller/larger and in turn cause other layout changes), when you save the project the files in which the forms are serialized in will have different values than previously for their left/top/width/height properties - and that will show up in a diff when you have the project in version control.
This is can be a bit annoying since when you want to see what changed in a form you have to mentally ignore all the position and size changes. Though TBH in practice personally i never thought much about it.
I used a graphical diff tool that showed both versions and allowed to revert unwanted changes with a couple of clicks. I think it was WinMerge. Also, I never opened the DFM designer unless I was going to make a change.
Top and Left need to be published properties, even for non-graphical components, so the designer can place them somewhere without covering one another. That's why they're declared so deep in the hierarchy.
The serialization code is one of the nicest parts of the framework. I was tasked once with translating an old and messy application. Translation tools, including the one by Borland, included in the enterprisey versions, were utter crap. I hacked the serialization code to extract the relevant strings into an Excel that we sent to the guy doing the translation and then use his output to create different DFM sets, all of them included in the exe, and selected when starting the application.
Actually everything about the IDE was great, there was a comprehensive API to make plugins ("experts") for the IDE, mostly undocumented, but Ray Lischner wrote a couple of great books about it and some nice guys created a set of useful utilities with source.