I was recently nominated to become a member of Embarcadero’s MVP program (click here for more info), and was invited to join last week! WOO HOO! It’s truly an honor to be recognized for the technical chops I’ve developed around Delphi — I’ve been working with it since it was released nearly 20 years ago now. In fact, Delphi’s 20-year birthday is coming up on Valentie’s Day next month. Continue reading
In the previous post, we examined four traditional ways of initializing objects such as forms in Delphi. There are two more approaches we’ll examine that aren’t used as much but result in much less coupling than the others: initialization methods, and call-backs. In this installment we’ll look at the former, and in the next we’ll look at the latter.
Remember that we’re discussing how to initialize objects here, including forms. It’s not always the case that you have data available in an easily accessible database table, so we’re doing this manually, which is not all that uncommon. In fact, I maintained a rather large application a while back that used a NOSQL database where we had to do the data queries outside the forms and pump all of the data into and out of the forms exactly like this, which is where I got the inspiration for this series of articles. In that code, I found virtually all of these approaches used to interact with their forms; there was not a lot of consistency throughout the project. (Actually, this is all leading somewhere inasmuch as I hope to present a simplified way of interacting with forms that can reduce the amount of “plumbing” code required to get data in and out of them.)
In the last post we started discussing selection forms and I stopped at the point where we were encountered a dilemma: the form is constructed with the form.Create() method but there’s data that’s not loaded into it yet. So how do you get the data into the form?
I’d like to take a slight detour for a minute and discuss something called dependency injection. Wikipedia defines dependency injection thusly:
Dependency injection is a software design pattern in which one or more dependencies (or services) are injected, or passed by reference, into a dependent object (or client) and are made part of the client’s state.
Any time you need to pass data into an object, it represents this design pattern. Some folks might quibble about whether the dependencies can only be “services”, or whether they need to be “passed by reference”. For this discussion, it doesn’t really matter — the point is, you have some data (fields, objects, or services) that needs to be injected into the object (a TForm in this case) and it affects the state of that object. When a form opens and you want the user to be looking at a bunch of fields already populated with data to select from, that is the initial state of the form.
So the question is, what’s the proper way of interacting with the form so it is initialized properly when the user sees it? Let’s look at our options within the context of the dependency injection pattern. Continue reading
This is the second part of a series I’m doing on the topic of interacting with forms in Delphi. This time we’re going to focus on a particular kind of form that I’ll call the “Selection Form”.
There are tons of simple selection forms that we encounter on most programs today: font selectors, brush selectors, date selectors, directory and file selectors, etc. The most common ones have standardized representations that become familiar to us fairly quickly, either because they’re a standard part of the operating system, or because the app developer came up with his/her own versions. These aren’t the kinds of selection forms we’re interested in.
The selection forms I’m talking about are used by an application when the programmer needs to find some kind of reference key for locating data for the user, often through a database lookup operation. Databases normally use integers as keys, called “IDs”, and their exact values are irrelevant. All you know is that any given ID lets you find one specific record.
So as a programmer, when you’re presented with a situation where you need to find a database record by ID and you don’t know what it is, you … ask the user. This is typically done with a selection form. They’re also called “lookup forms”. They’re usually displayed as pop-up forms displayed modally, which means they hold the focus until you close them.
This is the first of several articles I expect to write on the topic of (programmatically) interacting with forms in Delphi. This is a look “under the hood” at some stuff that a lot of Delphi Developers take for granted. I’ll survey a variety of approaches I’ve seen in working with forms, some recommendations I’ve got, and hopefully lay the groundwork for a new way to approach dealing with forms. Along the way, we’ll also take a look at how LiveBindings can play a role in this effort as well.
For those who don’t know, Delphi is a programming environment released in 1995 (Valentine’s Day, if I recall correctly). I’ve been using it ever since. It supports a language called Object Pascal, and it grew out of a very popular compiler called TurboPascal, the product that launched a company known as Borland, Inc., way back in the early days of home computers (back when they still ran MS-DOS).
(You can learn more about Delphi from the Embarcadero website.)
In the last article I posted, I made an effort to describe what the future of programming might be like if we’re to have any kind of quantum leap in the productivity of programmers. The software industry has revolutionized virtually every other field except our own. Today we employ the same edit/compile/debug form of iterative programming that has been used for over 50 years. That has got to change. We need something that’s more designed around dropping little logic blocks on a form and connecting them with lines that represent data flows. And it must be done in a way that allows the resulting diagrams to be executable.