Glaring Bugs still make Firemonkey Apps Unpublishable as of XE7.

I really wish I didn’t have to write these trolling blogs about Delphi all the time.   Truth is, I have really liked the tool for all of my 20-year career as a programmer.  I still use it every day.  I want to see it successful.  I think that is one of the reasons I dish out “tough love” all the time.

Right now I am stuck though.

It seems impossible to get the Delphi devs to fix any kind of bug in this language that would restore my faith in this tool.  I am so fed up with it, that I am in the process of starting an Indiegogo campaign to fix the perpetually broken compiler and language structure with an open-source alternative (not FreePascal).  The campaign should be live within a week.

Will anyone fund it?  I highly doubt it.  I think that my uses for Delphi don’t really fall in-line with the uses the general public finds for it.  Who needs an optimized compiler anyway right?  What’s wrong with a completely unoptimized, bloated, compiler that repeatedly loads the same constant into the same register over and over and doesn’t even do the most basic dead code elimination?  The sad truth is this quality of compiler is probably totally okay for most business apps.  The problem is, I’m writing services, I do very little with the GUI actually… and I am faced with either rewriting 2+ million lines of code, or building a compiler to rewrite it for me.

Regardless of the crude state of the compiler and language design (don’t get me started there), I would like to be able to count on FireMonkey for GUI apps when I need to, and, unfortunately I can’t.  I recently tried out a demo of Delphi Xe7 hoping and assuming that a showstopper bug that I reported over a year ago would be fixed with the update.

The bug was regarding how combo boxes and pop-up menus display on multi-monitor setups.   I reported that ever since Android support was added, pop-up menus would not be properly displayed on secondary monitors if the secondary monitor was placed to the LEFT of the main monitor.   This occurred both on Windows and OSX.  I reported the bug and was even so nice as to find the exact line of code in the source that caused the issue.

The QA person over there was quite attentive and started a conversation with me in the QC database, and even pointed to some potentially duplicate reports marked with “serious / highly visible” urgency… and it all seemed like the team over there was pretty alarmed about the bug and taking care of things. One of the duplicate reports was marked as “fixed”,  so I was under the impression that new builds of Delphi would fix my problem…. but… NOPE.   The bug is still there… marked as “fixed” and who knows when the QC guys will actually get around to busting some chops over there and ACTUALLY fix the problem.  I don’t know about you, but I’m not about to build an app that doesn’t display properly.   I don’t want the poor quality of the tools I use to reflect poorly on the apps that I write for my clients/customers.

Basic functionality failure such as this is embarrassing enough when it is an isolated incident, but unfortunately, this incident is not isolated at all, but rather typical.  I can point out dozens of blunders I’ve dealt with over the last decade, most/all of which are still not fixed 10 years later.   Clearly there is a systematic corporate culture problem over at Embarcadero.  And for god sake, someone needs to step up and take care of things… for god sake… hire a single Jr. Programmer to chase down these issues…. all it takes is one single dedicated Jr. programmer to fix this stuff!  Get it done!