Category: VCL

Why I Keep Choosing Delphi

Post author By Jim McKeeth
Post date 14-Aug-2017
14 Comments on Why I Keep Choosing Delphi

Early on I learned Turbo Pascal, which was a huge step up from the Basic and Batch File programming I cut my teeth on. When Delphi came along I thought it was brilliant and fell in love immediately. I had no interest in learning other programming languages or tools. Delphi did it all, and that was great. I found myself plenty of work and enough to keep my interest.

I was curious about other programming languages, from an academic point of view. I took a night school class in Assembly. I had a smattering of C & C++. Looked at some Ruby (back before it was hip), Java, JavaScript, etc. Eventually, I found myself spending a few years debugging laser printers, which ran a combination of C/C++/COM all on a Linux platform.

From there I went back to full-time Delphi programming, but the new company I was working for bought into the “there aren’t enough Delphi developers” myth and decided to move to C# & WinForms. We immediately were able to hire some new C# developers, but as we got to know them we found out they had more Delphi experience than C#, but they bought into the “there are no Delphi jobs” myth and rebranded themselves as C# developers. (This is what we call a circular argument or self-fulfilling prophecy.) In the end, the project took 4 times longer than it should have, despite having more developers, and “more modern developer tools.” They really should have stuck with Delphi.

I moved to a new job doing Delphi development full time, and then that company bought into the C# & Silverlight are the future. Since I had C# experience, I started working on the new Silverlight front end. The back end and the desktop app remained in Delphi (with a little C++). We all know what happened with Silverlight (if you even remember it . . .)

From there I ended up really branching out. I did a lot more work with C#, Xamarin, Java, JavaScript, Objective-C, and Oxygene (known as Delphi Prism at the time). There was still some Delphi mixed in too. I taught a few classes and workshops on Android development with Java. I learned to appreciate some of the benefits, strengths, and qualities of each. I found things about all of them I liked (less so about Objective-C).

It was at this point I could see that most developer skills work across languages, tools, and platform. There is value in knowing and using multiple languages. The basic tenants of each language influence the way you do things in other languages, in a positive way, helping you to look at problems in a different way. There are some projects, platforms, and problems that are best suited to certain programming languages and tools. For example, if you are working with the web, you need to know at least some JavaScript, HTML & CSS (the latter two not being programming languages, but I digress), even if you are using some sort of abstraction layer.

Throughout all of this, I still found myself choosing to Delphi for personal projects. Occasionally I’d try personal projects in other tools and languages as a way to get to know them better, but I still found Delphi to be a better solution for most general purpose projects. One of the defining characteristics of Delphi for why I keep coming back to it is that it makes the common tasks really, really easy while keeping the rest simple and possible.

Other tools that focus on productivity, make a small subset of tasks as easy as Delphi does, but also make anything beyond those tasks, or the that “ideal” scenario, hard or impossible. While other general purpose tools don’t do anything to optimize common scenarios, which makes simple tasks more complicated than they need to be.

Now with multi-platform development Delphi is more important than ever. The approach Delphi and FireMonkey provide make it quick and easy to do the most common tasks, while also keeping all the platform APIs and features within reach.

Delphi really invented the 3rd party component market as far as I am concerned. From the beginning, it shipped with all the source code for the VCL and also included a robust OpenTools API and component model making easy for others to extend the IDE, and build reusable components and libraries. All the technology partners are a huge part of why I choose Delphi.

Delphi also has a huge commitment to the code we as developers develop. I attend a lot of general software developer groups, and it is common to hear developers complaining about how they just finished porting their code to support a new version of their tools, only to have it all break again because a new release of their non-Delphi programming language or framework just came out. Often times they just throw it all out and rewrite to support a new version. Sure, Delphi it isn’t perfect, and sometimes there are incompatibilities or breaking changes from version to version, but by comparison, Delphi is so much better at this than any other language or platform out there that I have seen.

I started out choosing Delphi because it was what I knew. Now I choose Delphi because it gets the job done better than the alternatives. The fact it is faster for development is nice, but only part of the equation. I used to have a hat that said “Delphi does it all, especially Windows” and that is truer than ever today.

So why do you Choose Delphi? Share your reasons in the comments or on your blog #WhyIChooseDelphi

Audio podCast Cool Apps FireMonkey podcast TMS VCL

The Niagara Falls Lighting Episode

Post author By Jim McKeeth
Post date 20-Apr-2017
3 Comments on The Niagara Falls Lighting Episode

This episode is extra special in that it include a case study of the software behind the lights for Niagara Falls. Nick and I spoke with Martin Searancke of Dream Solutions, Ltd. in New Zealand, who is the architect of the Light Factory software used by the Niagara Falls Illumination Board to illuminate Niagara Falls. After you listen to the podcast you can read the case study write up here.

The software uses both VCL and FireMonkey. The backend control software is written in VCL and the frontend user interface side is written in FireMonkey. It also uses components by Mitov Software, TMS Software, and LMD Innovative.

A few links we mentioned

Navigator by Parnassus – A fantastic IDE add-in
The NEO Phillips Strand Lighting console – The software in the console is by Martin
Light Factory – Martin’s web site

Here is a little documentary about the new lights at Niagara Falls. It mostly focuses on the hardware side of things, but you can watch it knowing the software comes from your favorite development tools.

Niagara Falls Lighting Software Case Study

Introduction

The decision to upgrade the lighting that illuminates Niagara Falls seems as though it should be the main story but, it’s not. The part of the project we are interested in is the one where the Niagara Falls Illumination Board (NFI) added a requirement to build a more flexible color illumination scheme to replace the old guillotine color-changing scheme that had been in place since 1974. The guillotine color-changing synchro-server mechanical system was to be replaced by a digital color control system and the twenty-one 4000w Xenon lights were to be replaced by 1400 digital-friendly nine-light LED modules in which the LED’s would be multi-color rather than having to place a filter in front of the white light of the Xenons. The LED system of lights would be software controlled from a 22-inch touch screen from over a 2000 foot distance from the falls.

The Solution

The technical and engineering challenges to a project of this scope and magnitude were significant right down to the last task of choosing the lighting controller and connecting it with the 1400 LED light modules. The software that drives the system is housed in the controller and is built using Embarcadero’s Delphi Integrated Development Environment (IDE). The FireMonkey (FMX) application development platform is used to create the front end functionality, and the Visual Component Library (VCL) is used for the back-end services. FireMonkey and VCL are both integrated elements of the Delphi IDE.

The lighting controller was a commercially available machine marketed by Philips Strand Lighting as part of their NEO line of lighting consoles.

NEO Console running Martain's software

The existing software code in the NEO lighting console dated back a few years given that the console had been sold commercially before the Niagara Falls lighting project was even considered. The first challenge to overcome was to review the technical and performance requirements needed to accomplish the vision of the NFI and update the FireMonkey and VCL code to meet the required functionality. Then, came the customization of the code to accommodate all the connecting equipment that would drive the LED modules and the end user interface, the 22-inch touchscreen.

The overall objective of the new control console and software code within was not to try and upstage the majestic beauty of the falls but rather to organically enhance visual images of the falls at night when it couldn’t be seen otherwise. So, special effects such as strobing and other awe and wow factors were ignored in favor of techniques such as backlighting the falls to reveal hidden beauty in addition to a penetrating forward color-changing illumination. The results were nothing less than magnificent requiring new software profiles due to the color changing properties of the LED modules. The final result was ten preset modes for each side of the Falls (American and Canadian) encompassing color schemes to match naturally occurring, organic events such as the aurora borealis, sunset, sunrise, waves, and color gradients.

One unique capability that was requested to be programmed into the FireMonkey and VCL code was a user interface the allowed operators to use a touch-sensitive color-picker button on the screen to change scenes instantaneously. The LED lighting modules instantly responsive making these color changes dramatic and inspiring. A mobile interface module and application was created using FireMonkey to allow visitors and tourists to be able to manipulate the solid color palette and see the changes appear right before their eyes.

Conclusion

The Niagara Falls Lighting Project brought to light one of the real values of Embarcadero software. In this case, the Delphi IDE and its integrated parts (FireMonkey and VCL) is life-cycle engineered so that code developed years ago can be updated and reused to create an entirely new, cutting edge capability for new technologies such as LED lighting modules. This fit the Niagara Falls Illumination Board (NFI) requirements perfectly. The design of the system was mandated to done such that in the future, changes and additions can be easily accommodated. Embarcadero and its Delphi IDE proved its worth and was demonstrated to be able to meet future requirements as the Niagara Falls lighting system evolves and new technologies come online.

The Niagara Falls Episode [ 48:59 ] Download

Tags LED Lights, Niagara Falls

design FireMonkey User Interface VCL

FireMonkey vs. VCL

Frequently when I am talking about the VCL or FireMonkey I get some of these common questions:

Is VCL deprecated?
Which is better FMX or VCL?
If I am starting a new app today, should I use VCL or FMX?

FireMonkey vs. VCL

The first is easy to answer, the other two are a little harder. The VCL (or Visual Component Library) is NOT depreciated, nor will it be any time soon. As long as there is Windows and the Windows API, there will be VCL. Just recently in Marco’s Windows 10 Webinar he said “VCL is the best library for Windows desktop development and fully embraces Windows 10.”

The VCL gets new components, features and bug fixes frequently, but maybe not as often as FireMonkey. The reason is the VCL is a mature framework, while FireMonkey has been going through a lot of growth the past few versions (although it has stabilized a lot recently, and is reaching a more mature status.)

So which is better, and which to use? There isn’t a straightforward answer, but instead I can tell you the advantages of each, and you can make an educated choice for your next project.

Visual Component Library (VCL)

The VCL was release with the first version of Delphi. It is mostly a thin wrapper over the Windows API controls, but also includes a lot of owner draw controls. It uses GDI, Windows Handles and Windows Messages. This makes it subject to the same behavior as 90% of the other windows applications out there. If you want to you can inject a VCL button from your app into another app, or sniff messages sent to a different app and redirect them into yours.

As I said earlier, the VCL is mature, and so is the 3rd party component space. There are thousands of high quality VCL components, controls and libraries out there. Probably the most notable are the grids. The VCL grids are the best in the industry, and for good reason, our technology partners were making grids for the VCL before any other platforms had the idea of 3rd party controls. So if you want the best grid on the planet, you will probably use the VCL (although the FireMonkey grids are gaining fast).

Because VCL is mostly a thin wrapper on the Windows API, VCL based applications are much smaller than FireMonkey applications. Anymore this usually isn’t a huge deal with fast download speeds and huge hard drive sizes. But if you need a really small lightweight application, then VCL might be a good choice.

Because VCL has been around a while, you may have some existing VCL code that you want to integrate into your application. You could use a utility like Mida converter to convert it to FireMonkey, or something like Monkey Mixer or TFireMonkeyContainer to mix FireMonkey with VCL.

Generally if I am building a simple grid intensive application that I know will only run on Windows, then I find myself using VCL. Or if I need to leverage a specific 3rd party control, or Windows API feature that requires Windows messages. This is less and less frequent though.

FireMonkey Cross Platform Framework (FMX)

As FireMonkey is a newer framework you tend to see it covered more. A lot of people are still learning how to use it, and how to tackle cross platform development. The main advantage of FMX is that it is designed from the ground up to be a cross platform framework. It lets you design a single user interface that runs and looks great on Windows, iOS, macOS and Android. But that isn’t the only reason to use FireMonkey.

FireMonkey is based on the latest GPU frameworks: DirectX for Windows and OpenGL elsewhere. It supports both 3D and 2D rendering models, both of which are hardware accelerated. If you want to have some powerful graphic effects or 3D, then FireMonkey is probably going be your first choice. There are some really powerful 3D engines as well as some great graphics effects libraries for VCL, but FireMonkey has these ideas baked into it’s core.

FireMonkey is also a lot more flexible. You can embed any control in any other control with FireMonkey. This ability to build composite controls turns the smaller set of controls it includes into a much more robust set of controls. Also there are animations and effects that let you build fantastic, rich user interfaces with very little effort.

VCL has a respectable set of containers and alignments, but FireMonkey has many, many more, and again they are much more flexible. Another big difference is FireMonkey uses a single precision floating point number instead of an integer in laying out the controls. Much higher precision, but typically subpixel precision doesn’t buy you much. Where it does make a difference is when you scale on FireMonkey since it supports multiple pixel densities.

The most obvious reason to use FireMonkey is if you are currently planning to target multiplatform, or there is a possibility you might in the future (which is a pretty high likelihood). The other reasons are you want a more flexible UI or you plan to take advantage of 3D or other effects FireMonkey provides.

Conclusion

In summary VCL is amazing, and continues to get fixes and new features. It is a better user interface framework than any other out there, except maybe FireMonkey. So use VCL when you are only targeting Windows and don’t need the 3D, effects or flexibility of FireMonkey. Use FireMonkey when you are going multiplatform, or you new some of FireMonkey’s flexibility especially when working around graphics.

Both frameworks will be around for a while. As you use them both you will get a better feel for which to use in each situation. I’d love to hear your feedback about when you choose which framework.