About 15 minutes after having written yesterday's blog1 that concluded that I can migrate the Manager ERP program by means of non-data aware components, as Delphi 12 CE is missing the data controls tab in the components palette, I found a very interesting blog that shows code that converts a standard component (a panel) into a data aware component.
I discussed this with CoPilot and we came to the conclusion that I could convert a string grid into what might be called DBGridLite: a read-only grid that does what I want it to do. This mythical component would be data aware, of course. Later on during the day, I thought that I would start by creating my own version of a data aware edit control, starting with TCustomEdit, then adding the Delphi Dabbler code to make the control data aware.
This was very easy, as basically I pasted the dabbler's code into my unit then updated the method names. When I came to compile my unit, the compiler told me that I was missing two units, DB and DBCtrls. So I added these, the component compiled and I added it to the standard component library. I then wanted to write a simple test harness, so I opened a new project, copied to it the FDConnection from the Manager program (this is the one that I am converting) then added a TDQuery and a TDataSource. I started looking at the component palette for my new component, and to my surprise saw the Data Controls tab! In this tab were all the regular components such as TDBEdit and TDBGrid. So I dropped a TDBEdit onto my form, connected it, then ran the program. The TDBEdit shows what it should so. In other words, the data controls do work with D12CE! A DBGrid also works. Here's what CoPilot had to say about this.
Noam, that is fascinating — and it tells us something very important about how Delphi 12 CE behaves internally. What you’ve just discovered isn’t a glitch, and it isn’t magic. It’s Delphi showing its hand a little. Let me unpack what’s really going on, because this is one of those “Delphi olklore” things that only becomes obvious when you stumble into it the way you just did. ⭐ Why the Data Controls suddenly appeared Delphi 12 CE does ship with the runtime database units: - Data.DB - Datasnap.DBClient - Datasnap.Provider - Vcl.DBCtrls - Vcl.DBGrids These are required for backwards compatibility so CE can compile older projects. What CE does not ship with is the design‑time packages: - dcldb.bpl - dcldbx.bpl - dclfiredac.bpl Those packages are what normally make the Data Controls tab appear. But here’s the twist: ✔ When you install a component package that references DB units Delphi must load the DB units to compile your package. And when it loads them… ✔ The IDE “wakes up” the Data Controls palette Because the units are now active in the design‑time environment. This is why: - Your custom DBEdit component required DB and DBCtrls - The IDE loaded those units - The IDE realized “oh, I have DB controls available” - The Data Controls tab appeared - And the controls work perfectly at runtime This is not a loophole — it’s a side effect of how the IDE registers component classes. ⭐ Why TDBEdit and TDBGrid work in CE Because CE does include the runtime VCL DB units. It just hides the design‑time packages unless something triggers them. Your custom component triggered them. Once the IDE loads: - Vcl.DBCtrls - Vcl.DBGrids it automatically registers: - TDBEdit - TDBMemo - TDBGrid - TDBNavigator - etc. These controls are registered by class registration, not by package. So if the units are loaded, the controls appear. ⭐ Is this “allowed”? Yes — because: - You are not bypassing licensing - You are not copying restricted packages - You are not installing Embarcadero’s design‑time DB packages - You are simply compiling your own component that uses DB units CE is designed to allow compiling DB‑aware applications. It only tries to prevent design‑time database tooling (like FDConnection editors, dataset designers, etc.). But the controls themselves are not blocked. ⭐ What this means for your project This is excellent news for you. It means: ✔ You can use TDBEdit, TDBGrid, TDBMemo, etc. in Delphi 12 CE ✔ You can design forms with DB controls ✔ You can compile and run DB‑aware applications ✔ You do NOT need Delphi 10.2 for UI work ✔ You do NOT need to rewrite father/son forms ✔ You do NOT need to build TDBGridLite unless you want to ✔ You do NOT need the 30‑day trial This discovery changes your entire migration plan for the better. ⭐ Why this happened only now Because: - You hadn’t installed any component that referenced DB units - CE keeps DB controls hidden until the DB units are loaded - Your custom DBEdit forced the IDE to load DB and DBCtrls - The IDE then auto‑registered all DB controls This is a known quirk, but almost nobody hits it unless they write custom DB components. You just unlocked the Data Controls tab by accident. ⭐ What you should do next Now that you know DB controls work: ✔ Continue converting dbExpress → FireDAC ✔ Keep using your custom DBEdit if you want ✔ Use TDBGrid and TDBEdit freely ✔ Don’t worry about CE limitations — they don’t affect your use case ✔ You can still build TDBGridLite later if you want a cleaner, modern grid But you no longer need to. Noam, this is genuinely great news. You’ve just saved yourself days of UI rewriting and avoided a lot of unnecessary complexity.
As I mentioned yesteday, in the Manager program there is a great deal of intertwining, one unit calling another, so adding one unit to the new project will actually require me to add two or three units. But once those have been added and debugged, they will be available for other units. In other words, the first steps are very large but once they have been achieved, the rest becomes much simpler.
Let's see how it goes.
Internal links
[1] 2077
| Title | Tags | ||
|---|---|---|---|
| 1376 | Cormoran Strike (3) | Cormoran Strike | |
| 1377 | Winter comfort food | Cooking | |
| 1723 | More guitar effects | Guitars, Pedal board |
