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.
Someone posted a follow-up question to my earlier post on Quora (my last post here):
How do you see the process changing so programmers can be more productive?
It’s what I said in that last sentence of my earlier post: “I’m not sure what, but I bet it’s going to be a highly visual process that looks more like digital circuit design than programming.”
The first integrated circuits involved someone sitting down and drawing lines. They were literally etching multiple layers into a silicon substrate, similar to how photographic lithography is done. (It was, in fact, a photolithographic process.) That’s how they did it for a LONG time. It’s analogous to how we program today, by writing lines of code, line by line.
Someone on Quora posted this question:
You choose to be software engineer. Why? What incidents inspired you, what motivates you, what is it that still keeps you going?
When I was in high school, I was having lunch with a friend who invited me to the “math lab” to see what he was doing on a computer. I wasn’t sure what he was talking about, so I went mostly out of curiosity. This was 1972 and their “computer” was an ASR-33 Teletype connected to a time-shared system over the phone. My friend had written a program in BASIC that simulated a pin-ball machine. He figured I’d like to play the game. I was more interested in the code. I looked it over and asked a few questions about it. But mostly it made instant sense to me. “I thought everybody says computer programming is really complicated? This looks really simple.” He shrugged.
This was the fall semester of my sophomore year. I was in Advanced Geometry as my math class, and I was bored to death. The programming classes had always been restricted to Seniors in the AP program. As luck would have it, the Seniors that year weren’t interested. Nor were the Juniors. So the opened it up to us Sophomores in the advanced math (not AP) class and almost all of us gleefully said, “YES!” Go figure. I think most of us went on to become software engineers.