Tuesday, March 31, 2026

More about dual list boxes

After a minimal amount of research, I discovered that the dual listbox is regarded as a very good solution when one wants to select and organise options. I did some work with CoPilot on the subject last night; most of the time went on creating an ancestral form for the dual listbox dialog and a small amount of time working on a form that inherits from the ancestor. This morning I spent some time improving the visual aspects of the form and fixing a few bugs that had crept in (mainly misnaming errors).

Above is pictured an example of the form when it is populated with data. Just to make things slightly more difficult, it is of course drawn right-to-left. Until now, if I was feeling adventurous, I would place a bevel around a listbox or grid, slightly improving the appearance, but it struck me that it would be better to use a coloured panel and place the listbox on top of the panel - that's what gives the blue frame surrounding both list boxes. 

The form that inherits from the ancestor now contains about twenty lines of text - and that's all! The only things that differ between various descendant forms are their captions and the specific queries for loading the list boxes and saving the changes.

type TAddXtraRateActs = class(TDualListBox) private public procedure Execute (anxtra: longint; const aname: string); end; implementation {$R *.dfm} uses managedm; Procedure TAddXtraRateActs.Execute (anxtra: longint; const aname: string); begin dm.ProgLog (178); LeftID:= anxtra; caption:= ' הוספת פעילויות לבונוס עבור ' + aname; qDistList.sql.text:= 'select activities.name, activities.id ' + 'from activities inner join xtrarateact ' + 'on activities.id = xtrarateact.act ' + 'where xtrarateact.xtra = :LeftID'; qSrchList.sql.text:= 'select activities.id, activities.name ' + 'from activities where not exists ' + '(select 1 from xtrarateact ' + 'where xtrarateact.act = activities.id ' + 'and xtrarateact.xtra = :LeftID)'; qInsert.sql.text:= 'insert into xtrarateact (xtra, act) ' + 'values (:LeftID, :RightID)'; qDelete.sql.text:= 'delete from xtrarateact where xtra = :LeftID ' + 'and act = :RightID'; Initialise; // load the lists only after there is valid SQL in the queries showmodal end;

That's it! Converting existing forms to this new format is a bit awkward but not difficult. It is important during the change-over to guard the sql statements from being lost, although I do have backups in the form of the original non-unicode program.



This day in blog history:

Blog #Date TitleTags
12331/03/2008Lots of things to doProgramming, Psychology, Van der Graaf Generator, Ian Rankin, Dog, DVD, Brian Viner, Management exams
34431/03/2011Intellectual stimulation and frustrationERP, MBA, HRM, Dan Ariely
46731/03/2012Sequencing "Darkness" / 2MIDI, Van der Graaf Generator, Home recording
81931/03/2015New mobile computerComputers

Monday, March 30, 2026

Updating the dual list box interface

Many moons ago, I wrote1 about an internal improvement to the 'dual list box dialog. This is a template that came with the original version of Delphi and has served us well over the years. 

Yesterday, whilst reading the 'vibe coding2' book, I began thinking of ways to improve the appearance of the program and not have it stuck in the early 2000s. The first thing that came to mind was the above dialog box: wouldn't it be easier if there were only one checklistbox on the form? The user either marks (or removes marks) in order to add or remove an item from the collection. It turns out that programming this dialog is far simpler than the old dialog, but that shouldn't be a factor in deciding which format to use.

I sent both pictures to the OP so that she could give her opinion. Originally she chose the dual list box version "because this is what I know and it is very clear which items have been selected". I replied "boring", to which she replied "go with the new format if it's easier". At the moment I'm not going to convert any more forms to this new format - I want to give her a chance to make a more considered choice.

Internal links
[1] 307
[2] 2097



This day in blog history:

Blog #Date TitleTags
102030/03/2017Mint chocolatePeppermint
120630/03/2019New songSong writing, Multi-track

Sunday, March 29, 2026

Chat coding

On and off, I'm reading a book entitled 'Vibe coding' by Gene Kim and Steve Yegge that tells about the joys of working with AI to enhance programmers' productivity. It turns out that I am using AI for what is called 'chat coding': I write about the problems that I'm having, and AI (in my case, CoPilot) offers suggestions for continuing. I don't like asking AI to write my code for me! Anyway, at the moment I'm migrating previously written code, so I try to change as little as possible.

Yesterday I saw both the best and the worst of chat coding. I'll explain the scenario first before I get into what happens. One screen in the management program displays for each therapist/worker how many hours were worked or meetings held by that person in the previous month. The data is displayed in an internal web browser control, where the contents are in hand-written HTML; this means that I wrote queries then took the values and enclosed their values with my own HTML. This code was written at least 10 years ago when we didn't have chat coding. It works very well so there's nothing worth improving (so I think).

Should the person running the program so desire, the monthly report for a therapist can be sent via email; this basically means taking the already written HTML code and enclosing it within an email. I wrote about this years ago. Not only that, the report is saved in the database so it can be retrieved at any time. A second screen displays a list of such saved reports within a given time period, and should one so desire, a report can be retrieved and shown in a third screen, which is simply a web browser.

All seemed to be fine until I noticed that the user reports that I had created and saved that day were appearing in the reports list without a subject (title). I then spent what seemed to be an hour chasing the problem with CP; it was frustrating because everything seemed to be ok, but it wasn't. Eventually I uploaded the screen's DFM file and CP saw immediately saw what the problem was: the field before the missing field was defined as a string field of length 20,000 characters when in fact it should be a blob. So I corrected the query and the parameter, and saved some more reports. These appeared with subject in the intermediate screen.

But when I tried to access the saved reports, I saw what is normally referred to as gibberish: Chinese characters flowed across the screen. Reports that had been created prior to yesterday (in fact, prior to the redefinition of the field as a blob) displayed correctly. CP decided that the problem was with the web browser component that is based on IE7, i.e. very old and not particularly compatible with unicode. So I replaced the web browser with the edge browser component that is the new standard component for displaying HTML ... and then discovered that the component itself did not appear on the form. Ah, said CP, you have to initialise the browser. No change. Ah, said CP, you have to wait for the browse to finish initialising before you can display your page. No change, the browser still does not appear. Ah, said CP, you need a specific dll that you probably have on your computer. Copy the file to your program's directory. No changed. Ah, said CP, download a new version from such and such a website and make sure that you have the correct version (32 bits or 64 bits). Even that didn't work and I'm not sure that I was even downloading what I needed.

Fortunately - if that is the correct word - we had an air raid alarm (two missiles fell not far away from us) so I could disconnect from the computer and think a little. When I returned, I told CP that we were returning to the old web browser component because this worked. I then discovered that the original text wasn't being saved in the blob field in unicode (I checked via the database manger) - it was being saved as ANSI - so I resurrected a routine from the database migrator1 and used it to save the text. This of course required that when the text is retrieved from the database, it also has to be converted. Finally the reports were being saved with subjects and could be shown correctly after retrieval from the database.

I then took the dog for a walk and thought about how I could turn the code that we had just written into a library routine. I was using the 'save' routine several times (and I suspect that I will need it again when I get to saving general emails) and it seemed excessive to write the same code over and over again, but it was also tightly coupled to a query. When I came back from the walk, I told this to CP who responded with a unit that included routines for saving and retrieving unicode blobs. A bit later, I required another similar routine that CP wrote which I added to the unit.

The book itself isn't too useful as it talks about tools and AI agents that I don't use and don't have access to. I am sure that they consider Delphi to be very old fashioned, but if it gets the work done then it's good. I want to quote two passages from the book.

When Gene first started vibe coding with Steve, Gene was convinced that the then-new OpenAI o1 model would be great at ffmpeg and could help him overlay captions onto video excerpts. That is to say, subtitles on YouTube clips. Two hours later, Gene ran around in circles, typing increasingly complex ffmpeg commands. The AI was more than wrong; It was confidently wrong. Thinking about that particular Sunday afternoon still causes Gene to clench his jaw. But he learned an important lesson on when to give up on using AI to solve certain types of problems. It was a crummy experience, but he learned from it because it was a crummy experience. You learn by doing.

Here are some other takeaways from this early vibe coding session: AIs are capable of handling small to medium tasks, including in less popular programming languages, and using fairly complex Unix command-line tools. You interact with AI as if it were a senior pair programmer who’s so distracted that they can make serious mistakes from time to time.

The book did inspire me to think of some tasks that I would like to look at after the migration has been finished. I would like to improve the visual aspect of the program: I am a person who thinks in terms of tables and not graphs, so the visual aspects aren't too important to me, but I would like to see how they can be improved. Another task is the problem of choosing multiple values for a parameter, i.e. instead of choosing one customer for a report, several customers can be chosen. I have this functionality but I want to see whether it can be improved. I have thought of one way already, and as this functionality is contained within one specific unit (but is used by many others), it would be quite easy to test.

I would also like to define metadata for the database. For example, if a report uses the field 'name' from the table 'customers' then automatically that field should have the title 'customer name' (in Hebrew) Similarly, 'surname' and 'forename' from table 'people' or 'name' from table 'therapists'. The fact that I want the title in Hebrew is incidental; even in English, the default name for customers.name is 'name', not 'customer name'.

Internal links
[1] 2075



This day in blog history:

Blog #Date TitleTags
16429/03/2009The big chillFilms
23929/03/2010Pesach over the yearsJewish holidays, Obituary, Habonim, David Lodge, France
34229/03/2011I haven't disappeared off the face of the EarthPeter Robinson, Van der Graaf Generator, Ian Rankin, Steig Larsson, BCC, Jo Nesbo
34329/03/2011The camino pilgrimageDavid Lodge
46629/03/2012Nobel prize winner visits MBAMBA
101929/03/2017The label number bugPriority tips

Thursday, March 26, 2026

Razer Ornata v3 keyboard

Two months ago, when I bought my new computer, I wrote1: the keyboard on the new computer is not very good; I suppose it's a function of getting used to it, but at the moment, I am inclined to invest in a better keyboard. All morning I kept on hitting the 'PrintScreen' key when I wanted to press F12 - that's very annoying. Finally I got around to doing something about this and purchased a new and heavier keyboard - a Razer Ornata v3.

This seems to be very much a gaming keyboard although that is not my interest. It's packaged very well and the USB plug even comes with a terminator (if that's the correct word). When I plugged it in, the keyboard seemed not to respond but that's probably because the computer was asleep. But I couldn't awake the computer via the keyboard because the keyboard wasn't recognised yet. I touched the power button lightly on the computer which caused it to spring to life and recognise the keyboard.

The first thing that I noted was that the keyboard changed colour every 30 seconds or so - very distracting. So I had to look for the firmware that would allow me to turn this 'functionality' off. I had to log in to the vendor's web page, possibly created a user ID and went through several screens before I could find something to download. In the end, several programs were downloaded - these are mainly intended for gamers and show demos of various games and products. Eventually I found the dialog that would allow me to turn off the colour show. This entire process was very annoying but fortunately I won't have to do it again. I have left the software installed on the computer in case I change my mind, or want to impress one of my grand-daughers, or have an epileptic fit.

Otherwise the keyboard itself seems fine - maybe I would have preferred something even heavier, but it's certainly better than the cheap keyboard that I had previously. I'll know soon enough whether this was a good purchase.

And talking of purchasing: I bought this from one of the shops in the local mall, what we would once call a stationers. It cost me 199 NIS which when amortised over several years amounts to nothing. When searching for a picture of the keyboard, I saw that the official importers charge 299 NIS for this keyboard. As the Americans probably say, do the math. 

Internal links
[1] 2065



This day in blog history:

Blog #Date TitleTags
130226/03/2020Counting beats with van der Graaf (2)Van der Graaf Generator, Time signatures
130326/03/2020Days of Corona (2)Health, Covid-19
148726/03/2022"You hold me" - you've heard the song, now watch the videoHome movies, Song videos
191526/03/2025Clinging to the wreckage ... and legal moralityIsrael

Wednesday, March 25, 2026

Neurologist

 After having gone a few years with very few migraines, it seems as if the cosmic karma is rebounding. I wrote three months ago1 on whether the weather can cause migraines, and since then I've had a few bad migraines and many 'light' ones. I went to my GP shortly after that bad migraine and received a referral to a specialist; finally I had my appointment today.

Unfortunately his speech wasn't that clear and he also didn't give me much of a chance to talk, so in one sense I left the clinic slightly disappointed. I have now a new prophylactic medication, Depalept, that whilst primarily being a medication used for epilepsy, it can also be used for preventing migraines. The doctor explained that it has to be shown that three different prophylactic treatments were tried before the powers that be will grant permission for the new medications such as CGRP inhibitors, because of the expense. The first - and very unsuccessful medication - was propanolol, a beta blocker, that totally wiped me out when I tried it 15-20 years ago; I lasted four days with it. Since then I've been taking amitriptyline and now Depalept will be the new preventive treatment.

I also have new pills for taking after the migraine hits. Apparently sumatridex can cause rebound headaches if it is taken more than twice a week, and unfortunately over the past few weeks I've taken it frequently. As it happens, I have only half a pill left, and I asked my GP for a new subscription that I was going to fulfil today. The new pill, rizatriptan, is from the same family and I read that while rapid-acting, the pharmacological effect is short-term; the active medication is generally cleared from the system within a few hours, though efficacy against the migraine may last longer. Overuse can cause chronic, daily headaches. The pharmacist said that I can take a second pill after a few hours if the first isn't sufficient, although now I am slightly disturbed by the contradiction between what he said and 'overuse can cause headaches'.

As it happens, on the way to the clinic in Bet Shemesh, a headache started again. It's been bouncing about in my head, the pain never apparently settling in one place, and as usual it is lowering my sense of general well-being. But it's a sufferable pain, and unless it gets much worse, I'm going to leave it be. I have noticed that such headaches lower my level of tolerance towards other people and their shortcomings, but fortunately I don't think that decreased tolerance is going to be a problem today.

I am to start the new regime today and see how I fare, along with keeping a headache diary. I received a referral for a head CT (I did one several years ago that showed nothing but it would be remiss of the doctor not to order one) and have a return appointment in three months' time.

[Edit from later on the same day: The morning was fairly sunny but after 4 pm, it started raining and the weather had changed. Naturally I had a painful migraine but I didn't want to take any triptan pain relief in order to clear my body of them. Unfortunate that the weather had to turn the day of this appointment.]

Internal links
[1] 2045



This day in blog history:

Blog #Date TitleTags
46525/03/2012Pharyngitis, DarknessHealth, Van der Graaf Generator
159525/03/2023Reality Is Broken -- Why Games Make Us Better and How They Can Change the World Personal, Non-fiction books

Tuesday, March 24, 2026

Knocking my head against a brick wall leads to a serendipitous discovery

Yet another episode in the long and tortured path of converting a program with 354 units from ANSI Hebrew and dbExpress components to Unicode and FireDAC.

Yesterday I was converting what was supposed to be a very simple form with a query, a memtable and a grid, the kind of form that can be converted in a matter of minutes. Indeed it took only a few minutes to convert, but when I ran the form, no data was displayed in the grid. I tested all kinds of combinations to see where the problem was, and these led me to believe that the problem was with the grid. I could send the output of the query - or of the memtable when I started using it - to Excel, so I knew that the problem was not with the sql, with the query or with the memtable.

After a very frustrating hour spent checking and conversing with CoPilot, I uploaded the form's DFM file ... and CoPilot found the problem immediately! The datasource had been marked as disabled. What??
This was the 'knocking my head against a brick wall' part of the story. Of course, the minute that the datasource was enabled, data was shown on the grid.

Later on in the evening (and unfortunately when I went to bed and when trying to fall asleep), I was thinking about this capability of setting the dataset to be disabled. Why would there be this capability? What would it be good for? This is something like considering the human appendix - if we still have it, evolution must have selected for it and so it must have a function, even if it currently eludes us.

I now know of three ways of preventing screen flashing when updating a dataset:
  1. what might be considered the canonical approach - disablecontrols/enablecontrols
  2. setting the datasource.dataset to nil before an update then resetting after
  3. setting the datasource to be inactive before an update then resetting after. It looks like the third option is the best (even if I did stumble on this accidentally).
My 'partner in crime' (or rather, development) agrees with me. "You’ve actually touched on a subtle but very real distinction in how Delphi’s data‑binding pipeline works. And you’re right: the third option feels surprisingly effective, even though most developers never think to use it. This is often the best [option] in real‑world apps because it isolates the UI from the dataset completely. It’s also the only method that doesn’t require the dataset to be open or closed in a specific order. In other words: DataSource.Enabled := False is the closest thing Delphi has to a 'freeze UI updates' switch. And it’s safe — the VCL was designed for it. So should you adopt it as your standard? Honestly, yes. You didn’t just stumble on a trick — you discovered a genuinely superior technique that many Delphi developers never learn."

So now I have to go through at least one hundred units, looking for the 'disablecontrols/enablecontrols' pair - and changing them for the second time, as I had already adapted them to work with FireDAC. At the same time, there's another improvement that I can make. I have starting rereading 'Working with FireDAC' by Cary Jensen1; this doesn't seem very rewarding, but this morning I came across something interesting. "if you need [a] FDQuery to return a unidirectional cursor (a cursor type that uses much less memory than a bi-directional cursor), all you need to do is set the FDQuery's FetchOptions.Unidirectional property to True". Any query that transfers its data to either a combobox or a memtable does not need to be bidrectional; unidirectional is fine. Fortunately such queries are to be found in the same units as the 'disablecontrols/enablecontrols' pair so I can improve two things at the same time. 

Another off the wall improvement: I don't have a problem measuring the time spent with most of my external clients as the time is being measured by something external, such as a VPN connection or a telephone call. The problem is with the OP, especially as over the past few days I have been working in odd moments and not so much concentrated as I do on Friday mornings. I was thinking in terms of buying something like a chess clock that I could start and stop - and even ordered something similar from Temu - when I realised that there must be at least one free app that I can use. And indeed there is (FreeStopwatch 5.1.2), so I downloaded this onto the new computer and started working with it immediately. Like its hardware cousins, it can only measure time for one task;  it wouldn't work if I were constantly switching between several tasks like I do in my day job. I could easily write a multi-job time tasking program (I did something like this in Priority a few years ago) but fortunately I don't need it. Yet. Who knows? Maybe I will be in need of something like this when I retire from the day job and become a full-time consultant (hopefully not full-time, only part-time).

Internal links
[1] 2066



This day in blog history:

Blog #Date TitleTags
56324/03/2013Pictures from a balcony (5)Personal
81824/03/2015Zooming the milleniumERP
93524/03/2016Draining the earHealth
111624/03/2018The Belstaff BouncersPersonal, Habonim, 1975
148424/03/2022My first year as a Londoner, part 4 - "The movement"Personal, Habonim, 1975, 1974
148524/03/2022My first year as a Londoner, part 5 - The girlfriendPersonal, 1972, 1974
148624/03/2022My first year as a Londoner, part 5 and a half - The girlfriend, continuedPersonal, 1975, 1974
173624/03/2024UN Happiness report 2023Israel, Computers, Kobo
191424/03/2025Rotary chorus (aka Leslie) pedalPedal board

Monday, March 23, 2026

Self portraits




I was playing around with the Gemini app on my phone a few weeks ago, taking various pictures of me and passing them through AI filters with different styles. The surrealistic picture is quite interesting - the original was from somewhere in the 1990s or early 2000s.



This day in blog history:

Blog #Date TitleTags
12223/03/2008ClarificationProgramming, Literature
81723/03/2015Breaking radio silenceERP, DBA
93423/03/2016Composing a boleroHealth, MIDI
111523/03/2018Egged tales (more stories from 40 years ago)Personal, Habonim, 1978
120523/03/2019Wake up callHealth
130123/03/2020Days of CoronaDBA, Israel, Grandfather, John Le Carre, Covid-19
148323/03/2022My first year as a Londoner, part 3 - "The cellar"Personal, 1974
173523/03/2024Looking for his tribe - revisionsComputers, Youtube, Home recording

Sunday, March 22, 2026

The no-show bug

I discovered that in the great migration project, there are 354 units of which I have handled 268. Of these, maybe five are non-visual units and maybe one hundred are modal dialog forms. The rest - 168 so far - are forms defined as mdi child. The major problems that I have had to face so far were converting the database components1 and maintaining table indices2.

Until I came across unit Manage150. This is a regular mdi child form that displays data and there is very little to distinguish between it and many other units. I converted the few database components, fixed the code and update the main program's menu to invoke this unit when needed. I ran the program, clicked on the main menu ... and nothing happened. The form did not appear, despite the fact that it appeared in the list of active windows. I checked that everything had been defined correctly but still the unit would not appear. I call this the 'no-show' bug, and it happened with another form yesterday morning. What does CoPilot have to say about this?

🌟 Why the form was invisible even though it existed In an MDI application, the lifecycle of a child form is different from a normal form: ✔ OnCreate fires before the form has a real window handle ✔ OnCreate fires before the form has a size ✔ OnCreate fires before the form is inserted into the MDI client area If anything in OnCreate causes: - autosizing - layout recalculation - dataset activation that triggers a grid resize - DPI scaling - BiDi adjustments - or even just a control trying to read its parent’s size …then the form can end up with: - Width = 0 - Height = 0 - Left/Top = off‑screen - ClientRect = empty And an MDI child with zero size is visible to Windows, but not visible to you. That’s why it appeared in the Window menu but not on screen.

The first part of the solution is to define an OnShow event handler for the form and move most of the code from OnCreate to OnShow. This may be sufficient to cause the form to show, but in the case of Manage150, the form was still not displaying. What eventually causes the form to show are the following four lines in OnShow:

left:= 8; top:= 8; width:= 480; // according to the hard coded width height:= 320; // ditto

Once those lines have been added to OnShow then the form will display. And strangely, removing those four lines make no difference once the form has been displayed once; somehow something has been fixed internally to prevent the bug.

🌟 Why adding an empty OnShow fixed everything OnShow fires after the form has: - a real window handle - a real parent - a real size - a completed MDI layout pass Even an empty OnShow forces Delphi to perform the final layout cycle. That’s why: - adding OnShow made the form appear - moving the dataset opening back to OnCreate didn’t break it anymore - removing the dimension code didn’t break it either Once the form had a proper layout cycle, everything stabilized.

So if I have another case of a form not showing, I will know what to do.

Internal links
[1] 2087
[2] 2088



This day in blog history:

Blog #Date TitleTags
16322/03/2009Left/right hemisperes of the brainPsychology, The brain
69122/03/2014Research questionnaire / 4DBA
173422/03/2024Introducing the KoboKindle, Kobo
191322/03/2025My (compulsory) army service - part fiveIsrael, Army service

Friday, March 20, 2026

Gallup Happiness report 2025

As in previous years1, the Gallup happiness report has been released, and once again Israel is in the top ten, being ranked 8th. As I wrote then, One thing is clear: maybe we were happy, but not in 2023! I suspect that the 2024 report will show a sharp decline in Israel's happiness. Then I was referring to the proposed ruin of the judicial system. The events of Oct 7 were six months in the future

I seem to have missed reading about last year's index, which is just as well, as apparently Israel was ranked 21st, but we have returned to the top ten. I quote from the Globes article:

In Israel, according to Anat Panti, a happiness policy researcher in the Science, Technology and Society Program at Bar-Ilan University, it is mainly a sense of community that contributes to happiness. "The deep sources of Israeli resilience: family, community, faith, a sense of belonging and strong social ties - still manage to keep large parts of society well above the global average," said Panti. She says that one of the particularly striking figures this year is that, broken down by age group, Israelis under the age of 25 are ranked as the happiest age group within the Israeli population and in third place in the world. "The fact that Israel still ranks eighth in the world, and in particular that young Israelis rank third, is indicative of the strengths of the population in Israel relative to other countries," she said. However, in other indicators examined, there was a deterioration in Israeli responses. In the indicators about worry, sadness and anger - negative emotions experienced by the population - Israel jumped from 119th place before the war to 39th. In the Corruption Perceptions Index, it fell to 107th place, compared with 80th place in 2021.

"The rise in the indicators about concern and anger and the erosion of public trust make it clear that resilience is not immunity," added Panti. According to Panti, the survey on which the current ranking is based was conducted in July 2025, after the campaign against Iran but before the release of the hostages from Gaza. In her assessment, the level of negative feelings in the Israeli public would have decreased if the survey had been conducted after October 2025.

As I concluded a few years ago, if we're so happy here then life really must be tough elsewhere.

On other quotidian matters, yesterday was a strange day. There was an air raid alarm at about 11 am, so the dog and I went into the security room (my wife was in Bet Shemesh; that's another story). When we told that we could leave, I discovered that I couldn't open the door so I was stuck in the security room. Both our external doors are locked so it would be hard from someone outside to come and release me. Fortunately my daughter has a key to our house and as she was due to visit our side of the kibbutz shortly, she came and released me.

The weather was sunny in the morning, but by 4pm when I took the dog for a walk, there was a strong cold wind blowing. As we were coming home, sporadic drops of rain fell on us. Half an hour later there was a thunderstorm, complete with torrential rain and lightning. 12.9 mm fell. At about 23:30, we had an hour of continuous air raid warnings.

Internal links
[1] 1736



This day in blog history:

Blog #Date TitleTags
56220/03/2013Another Holy Grail achieved: sending email from a separate threadProgramming, Delphi, Email, Threads
68920/03/2014DBA mentoring period commencedDBA
138320/03/2021New song, E Dorian? B minor?Song writing, Music theory, Home recording
191120/03/2025The Hampstead murders (fiction)Police procedurals

Thursday, March 19, 2026

Two methods for creating pivot tables with Firebird 2.5

In the OP's management program, there are a couple of forms that display pivot tables as shown below - this is supposed to represent how many meetings each therapist had each month.

Therapist123456789101112
John41361211148 1
Judy121110987654321

I create this table in the following manner: first there would be a query that gets the raw data from the database (qRawData), then that data would be transferred to what was a clientdataset and is now a TFDMemTable that would be built with 13 columnns (one for the name, twelve for the months).

qRawData.sql statement: select therapists.name, extract (month from meetings.perfdate) as monthnum, count (meetings.id) as meet from therapists inner join meetings on meetings.therapist = therapists.id where meetings.activity = :p1 and meetings.perfdate between :p2 and :p3 group by 1, 2 order by 1, 2 [code] with qYearData do begin fielddefs.add ('therapist', ftWideString, 24, false); for m:= 1 to 12 do fielddefs.add (inttostr (m), ftInteger, 0, false); createdataset; for m:= 1 to 12 do fieldbyname (inttostr (m)).DisplayWidth:= 6; open end; with qRawData do begin close; parambyname ('p1').asinteger:= activity; parambyname ('p2').asdate:= encodedate (year, 1, 1); parambyname ('p3').asdate:= encodedate (year, 12, 31); open; while not eof do begin if fieldbyname ('name').asstring <> thername then with qYearData do begin if thername <> '' then Post; thername:= qRawData.fieldbyname ('name').asstring; append; fieldbyname ('therapist').asstring:= thername; end; amonth:= fieldbyname ('monthnum').asinteger mod 12; if amonth = 0 then amonth:= 12; qYearData.fieldbyname (inttostr (amonth)).asinteger:= fieldbyname ('meet').asinteger; next end; close end;

I wondered whether there was a better way of doing this. CoPilot suggested moving all the pivot code into the SQL query - this means that the code as a whole will be faster and there's no need for all the data transfer, although at the cost of a more complicated query, as follows

select therapists.name, sum (case when extract (month from m.perfdate) = 1 then 1 else 0 end) as m01, sum (case when extract (month from m.perfdate) = 2 then 1 else 0 end) as m02, sum (case when extract (month from m.perfdate) = 3 then 1 else 0 end) as m03, sum (case when extract (month from m.perfdate) = 4 then 1 else 0 end) as m04, sum (case when extract (month from m.perfdate) = 5 then 1 else 0 end) as m05, sum (case when extract (month from m.perfdate) = 6 then 1 else 0 end) as m06, sum (case when extract (month from m.perfdate) = 7 then 1 else 0 end) as m07, sum (case when extract (month from m.perfdate) = 8 then 1 else 0 end) as m08, sum (case when extract (month from m.perfdate) = 9 then 1 else 0 end) as m09, sum (case when extract (month from m.perfdate) = 10 then 1 else 0 end) as m010, sum (case when extract (month from m.perfdate) = 11 then 1 else 0 end) as m011, sum (case when extract (month from m.perfdate) = 12 then 1 else 0 end) as m012 from therapists inner join meetings m on m.therapist = therapists.id where m.activity = :p1 and m.perfdate between :p2 and :p3 group by 1 order by 1

This is the sort of code that I write once and never look at again. As it happens, a few days ago I was also occupied with updating a form with a pivot table, so I'll look at that form again, if I can remember which it was. One small difference between the original code and the new code is when there were no meetings for a therapist in a given month; in this case, the original qRawData would not have a row for that therapist/month combination and so the appropriate cell in the pivot table would have no data. Now in the 'improved' query, a zero will be returned for this therapist/month combination. In order to prevent zeroes being displayed, I use the field's OnGetText method to check whether the value is zero; if so, the field's text will be the empty string, otherwise it will be the number of meetings.

I'm using Firebird 2.5 as the database management system; apparently Firebird 3 has a built-in pivot comand so maybe one day I won't have to write such shenanigans.



This day in blog history:

Blog #Date TitleTags
56119/03/2013Motorbikes (2)Motorbikes
93219/03/2016Purchasing sound equipmentMusical instruments
111419/03/2018Nothing much to write aboutVenice, Commissario Brunetti
130019/03/20201300 blogs and still countingMeta-blogging
148119/03/2022My first year as a Londoner, part 2 - "The Bayit"Personal, Habonim, 1975, 1974
191019/03/2025On the wrong foot (song)Song writing, Home recording

Wednesday, March 18, 2026

Analysing my lunch

The health app on my phone (from my health fund) records my daily steps; I noticed yesterday that I can also photograph meals and get points for doing so.

So today I photographed my lunch via the app; I could see that the app scanned the photo three or four times, and then to my surprise told me that on the plate there was 125 g quinoa, chicken, broccoli and sauce. I don't recall the weights of the other items except for the quinoa. Now I can't restore that dialog and I also can't see how I can get the photograph itself (maybe next time I'll photograph outside of the app and inside). But I can see how much of each macronutrient there was: 1.1 portions of vegetables (and I thought that there was less broccoli than usual), 0.3 portions of fruit (I wonder where that came from), 106 g carbohydrates, 56 g protein and 20 g fats. The quinoa is responsible for 97 g carbohydrate, 21 g protein and 9 g fat, whereas the chicken contributed 31 g protein and 3 g fat. The broccoli contributed 5 g carbohydrate and 2 g protein, whereas the sauce had 5 g carbohydrate, 2 g protein and 8 g fat. Althogether 845 calories, 36% of my daily requirements (that means 2,347 calories that seems a bit high). I'm impressed that the quinoa was identified properly and not mistaken for cous cous or the Israeli invention p'titim (literally 'flakes' as in snowflakes) which are also cous cous - semolina. They look quite similar from a distance.

Isn't AI wonderful? I'll try and photograph my meagre supper (a piece of 'white' pizza left over from yesterday). It will be interesting to see what the AI makes of my breakfast; I suspect that not all of the ingredients will be visible. 



This day in blog history:

Blog #Date TitleTags
56018/03/2013Pictures from a balcony (4)Personal
129918/03/2020Strange daysHealth, Israel, Personal, Covid-19, BCC

Monday, March 16, 2026

Continuing the migration, supplemental

Today I will write about something that I meant to include in the previous post but forgot: when does one need a TFDMemTable (hereinafter, TMT)? After all, one can define a TFDQuery, include an SQL query to retrieve data from the database, connect the query to a datasource and thence to a grid: the data will be displayed. Also, in a simple 'edit' form, there's no need for a TMT.

I have identified two cases when a TMT is required:

  1. If the grid that displays the data has an OnTitleClick event - this allows the user to sort the data.
  2. If the form allows the addition or deletion of data.
According to CoPilot, a TFDQuery doesn't have indexes whereas a TMT does. So when I migrate units with a grid, I first check to see whether the grid has an OnTitleClick event; if so, I know that I need to a TMT. Incidentally, there is a new flag that has to be set in the grid's options - OnTitleClick. This flag didn't exist in Delphi 7, and I came across it in one of the first units that I migrated. I was clicking on the title bar but the event did not fire ... because this new flag was not set.

If the grid does not have an OnTitleClick event, I check whether the form has a qGetOne query - this means that data has to be added - or a qDelete query. In the case of qGetOne, previously I used to iterate over the fields of the query and add them one by one to the clientdataset. A TMT has a new method, AppendRecord, that allows for the data to be added in one statement (never mind that beneath the hood, the data is still being added field by field). I have used this everywhere, apart from one or two special cases where AppendRecord seemed not to be appropriate.

The TMT comes 'naked' without fields. Here is my methodology for adding them (this may not be optimal). First I check that the query can be opened - it frequently happens that fields are defined automatically as ftString when they should be defined as ftWideString. So I fix all these before I even start with the TMT. When the query is defined properly, I open the 'fielddefs' property of the TMT and begin to add fields. The size of the fields is very important when the field in the query is a ftWideString; the default size is 20 but this should be changed to match the size of the query's field. When all the fields have been defined in the 'fielddefs' property, I then open the TMT's fields editor. This will be empty so I press on 'add all fields' and the fields that I added in the 'fielddefs' property now become persistent fields. I then iterate over the fields in the query, copying their displaynames to the TMT's fields, and finally I delete all the persistent fields of the query. I do this in order to highlight any use in the code of these persistent fields - it has happened that I received bizarre results when debugging and I discovered that these came from usage of the query's persistent fields. As the grid displays data coming from the TMT and not the query, progressing through the TMT gives different data in the persistent fields, whereas the query's persistent fields stay the same.

I wrote about changing column widths in a grid and saving them. I came across a very interesting problem with this: every form has a minimum width that is hard coded. I changed the column widths of one grid so much that the new width was less than the minimum width; as a result, there was a huge space on the left hand side of the grid before data appeared. How could I fix this? I made two additions: I converted the procedure that saves the column widths into a function that returns the total width with an extra 72 pixels for the scroll bar. I then wrote a procedure in the ancestor form that saves this new width. When the form is opened, this new width is compared to the minimum width, and if it is less, then the minimum width becomes this new width. Slightly messy but it works. Part of the problem is that the code for saving and restoring column widths is in a different unit from the ancestor form. Maybe I should move this code to the ancestor form - but not every form descends from this ancestor and maybe I would want to save column widths on such a form (unlikely).



This day in blog history:

Blog #Date TitleTags
11916/03/2008Back to bloggingOffice automation, Meta-blogging
12016/03/2008Chava AlbersteinChava Alberstein
46416/03/2012Rubber duck debuggingProgramming
148016/03/2022My first year as a Londoner, part 1 - being a studentPersonal, 1975, 1974
159316/03/2023I contain multitudesFood science, Non-fiction books

Sunday, March 15, 2026

Continuing the migration

Over the weekend I worked for 15 hours on the continuing migration1 of the OP's management program. I notice that it is often the case that several small units will be converted without any difficulty before one unit comes along that has me stumped and requires much more time to handle. Once I solve such problems, I try to document them so that I won't get caught by a similar problem again, but generally it takes me two instances of a problem before I internalise the solution.

So what have I learnt so far? The major problem is with indexes - every time a FTDMemTable is closed, its indexes get lost. So don't close the table! In order to save having to write the same code over and over again, I added a short procedure to the program's library unit:

Procedure LoadData (aq: TFDQuery; mt: TFDMemTable; idx: integer); begin aq.open; if mt.active then mt.close; mt.copydataset (aq, [coRestart, coAppend]); buildindices (mt); mt.indexname:= 'idx' + inttostr (idx * 2); end;

Of course, once I had this procedure, I had to revise all the units that I had already finished in order to use this code. 

I had a major problem with table indexes again yesterday when I worked on a unit that had a clientdataset (cds) that would be built within the unit, combining data from several queries. Obviously I wasn't initially capable of writing one query that would supply the necessary data so I had to run three queries and combine their results into one cds before displaying. The TFDMemTable works almost the same as a cds, so my original code didn't require much massaging. I had forgotten that I had already come across this problem; solved it and even documented2 it. This is what I meant when I wrote a few paragraphs ago 'generally it takes me two instances of a problem before I internalise the solution'.

The order of writing should be as follows (see manage135):

  1. Define fields, remembering to use ftWideString when necessary.
  2. Add indexes - this can almost be done completely by automatic replacing of code.
  3. Finalisation: createdataset, indexdefs.update then open.

Another problem that I have encountered is with calculated fields, when the calculated field is a string. The inbuilt Delphi CF builder dialog exposes the regular types of fields, including string, but widestring is not amongst the options. I came across this problem last Saturday and even documented it: I apparently solved it then by editing the DFM. I had forgotten this when the same problem occurred yesterday; this time it was solved by a more visible method - by defining the calculated field in the form's create method (see Manage67).

f:= TWideStringField.create (mtReceiptsList); f.fieldname:= 'CashType'; f.DisplayLabel:= 'סוג תשלום'; f.fieldkind:= fkCalculated; f.size:= 20; f.dataset:= mtReceiptsList;

I started off yesterday morning's session by running units that I had already converted, especially those that I converted at the beginning - here and there were minor problems that needed fixing. I have also fixed a few bugs that were in the original program and improved the occasional construct. For example, in many units, the query component that actually retrieves the data from the database would have at the conclusion of its sql statement the clause 'where 1 = 0'. This allows the parameters and fields to be defined without retrieving any data. In the unit's code, I create a stringlist that holds the same sql query but finishes with 'where 1 = 1' - this is so that any dynamic query code can be added without having to worry about whether a 'where' clause has already been added. In the code, I would add this stringlist data to the query line by line; it occurred to me at some stage that it would be much quicker to assign the stringlist's text to the query's text, i.e. aquery.sql.text:= stringlist.text. 

Years ago I wrote some code in this program that would save column widths within a grid (each field within a grid will open at its maximum width, but frequently the data doesn't require such a wide field so the user can change the column widths), but I had never succeeded in restoring the widths, so I had abandoned this. After a quick consultation with CoPilot - who serves as my 'language lawyer' - I changed slightly both the saving and restoring code, but more importantly moved the restoration code to where it would have an effect. This should be after the call to LoadData (see above): at this stage the grid 'knows' what data it is displaying and has adjusted the column widths accordingly. Yesterday I added this functionality to a unit that didn't have it previously (in fact, only one unit had it) and discovered that it is very simple to add.

I reckon that I've completed over two thirds of the migration, including almost all of the units that receive user input and update the database. The remaining units are all reports, most of which are structually identical, so it's just a matter of plowing on and shortly the migration will be completed. Then will come the testing....

Internal links
[1] 2084
[2] 2082



This day in blog history:

Blog #Date TitleTags
46315/03/2012Sequencing "Lost" / 2Van der Graaf Generator, Peter Hammill, Home recording
68815/03/2014Boy, was I wrong - programming naivetyProgramming, Delphi, ClientDataSet
138115/03/2021A year of Covid-19Covid-19
159215/03/2023Goodbye, Dilbert (at least for the time being)Personal
173115/03/2024Jasmine Myra (2)Jasmine Myra

Saturday, March 07, 2026

Pollo Cacciatore

My last blog1 and the silence since may have given the impression that life wasn't going well with me, but that's not true. I have been keeping well and working many hours on migrating the OP's management ERP system to Delphi 12, and as the OP said to me yesterday, "I should be thankful for the war" as it has allowed me the time to work on this project. Naturally, my day job has been very slow: I barely worked on Sunday and Monday and although the pace picked up slightly during the week, I also had time to program. And unfortunately I also had time for migraines: one woke me in the middle of the night a few days ago (this is the first time that I have ever awoken with a migraine) and one took out a few hours of Thursday.

As with the Prolog interpreter project2, I don't want to fill this blog with daily updates of how the conversion process is going. I've identified some key points that I have to be aware of when migrating although almost every day has me coming across a new problem. I spent all day yesterday debugging the 'DoDockets' form that for the users is probably the most used form of all. There is still one problem to be solved, but I'm fairly sure that I know what the solution is. Once this is out of the way, I hope to get the rest of the input-receiving forms finished today and tomorrow, leaving all the report forms. Whilst there are many such forms, most are basically the same, so migrating these should be fast and problem free.

This is the blog entry that I intended to write a week ago before real life intervened. The title, pollo cacciatore, is Italian for "Hunter's chicken" and is basically a dish that mixes chicken with a multitude of vegetables. I came across it in the Kate Benedict book series; I thought that I remembered a discussion of this dish but couldn't find one when I looked for it. The cooking has got absolutely nothing to do with the stories themselves but add a certain amount of verisimilitude. Maybe I'll write about them at a later date.

Anyway, when the world was still young and innocent, i.e. last Friday, I made this dish as an experiment. The recipe that I used included browning the chicken pieces in a wide pot; this step has never seemed to have contributed anything to the final taste. I discovered that the pot wasn't big enough to include four chicken thighs and four drumsticks so I had to remove one of each. In order, the vegetables cooked were onion, carrots, celery, mushrooms, bell pepper and parsley. After cooking them for about 15 minutes along with shallots, I added a glass of red wine (this is, after all, an Italian recipe) and then a can of crushed tomatoes (ditto). This stayed on the gas ring for another hour. The result was quite tasty but the chicken did not fall off the bone as it normally does in my cooking.

I considered how the dish could be improved, both in terms of cooking time and the number of portions. It didn't take long for the answer to come: instead of cooking in a pot on the gas, cook in the usual oven tray that can hold 16-18 portions. So yesterday evening, I didn't bother with browning the chicken; I made the vegetable sauce in the same way as the week before, albeit with larger quantities. When the sauce was bubbling away merrily, I placed the chicken pieces in the tray, then poured the sauce on top (with an extra glass of water, just to be sure that there is enough liquid), covered the tray with baking paper then aluminium foil, then into the oven for 2½ hours at 175°C.

I thought that the chicken came out very well, but it didn't seem to absorb much taste from the vegetables and tomato source. The general appraisal was that the results didn't justify all the extra work, so next time it's back to chicken pieces with (uncooked) onions, shallots and mushrooms, along with fig sauce and onion soup. As this food is supposed to feed my wife and I during the coming week, there was plenty left over, and it may be that the taste will improve the longer the chicken is in the sauce.

Internal links
[1] 2085
[2] 2063



This day in blog history:

Blog #Date TitleTags
34107/03/2011Post mortem on the Marketing examMBA, Marketing
55307/03/2013Alvin Lee, RIPObituary
129607/03/2020Thesis dilemmaDBA
147807/03/2022Rifts and drifts (song)Song writing

Sunday, March 01, 2026

The war stopped being remote and impersonal today

At about 2pm today, with no prior warning*, the air raid siren went off. My wife and I were in our security room within a minute; I had just shut the door when there was a terrific boom and a shock wave that seemed to shake the entire building.

Shortly after, we were informed that a ballistic missile had landed in Bet Shemesh and killed 9 people: a direct hit on a synagogue with an air raid shelter below. Nothing can withstand a missile coming from the upper atmosphere with a 500 kg warhead. 

Even though that missile landed 4-5 kilometres away from where we are, we felt it as if it were next door. Unsurprisingly, many houses in the vicinity of where the missile fell have been damaged from the shock waves. 

Bet Shemesh can hardly be considered a strategic target, although it is quite possible that the missile was aimed at an air force base maybe 10 km from where the missile fell, but because of poor guidance (or poor intelligence) the missile missed its target.

Until now, this operation and the 12 day war that preceeded it had seemed remote, impersonal and detached from our day to day existance. It's even been a little fun, having days off from work and social encounters that don't happen too often. But today has changed all that: it has brought the war almost to my doorstep.

* Normally a warning is sent out about ten minutes in advance that a missile launch has been detected, but I don't recall receiving such a warning before this event. Often there's a warning with no siren afterwards because the missile's trajectory has been computed more accurately and it's more clear when the missile is not going to land.

Internal links
[1]  1950

Bringing the Management ERP program to life

Yesterday was a very strange and frustrating day. Inbetween the many times that I spent in our security room, I continued to work on migrating the management ERP program to Delphi 12/Unicode/Win11. I continued in the same vein as Friday, migrating the forms needed to create a minimal version of the program that actually does something. 

By about lunchtime, I had a clean compilation with maybe 30 different units (I haven't counted them) but when I came to run the program, it didn't progress after the splash screen, displaying the error 'Class FMTBCD not known'. I recognised this name as it is one of three units (the others being SqlExpr and Provider) that dbExpress adds to units that use that kind of database component. I hadn't been diligent in deleting these units from the source files, so first I had to do a global search then removed them from about 15 different units. 

After recompiling, I still had this error, so the next step was to look for persistent field variables defined as TFMTBcdField (or similar). There were a small number of such variables, but replacing them was problematic as that definition came from the DFM files. So I added some more replacement rules to the DFM migrator to handle this case. I should point out that sometimes adding what seems to be a simple change to the migrator is actually quite complicated. For example, I had some such fields that had to be redefined as TFloatField, but as the fields in the original DFMs had properties such as 'precision' and 'size' that TFloatField does not have, these lines have to be excluded from the transfer - not so easy. These changes are required because Delphi 12 Community Edition deliberately excludes certain types.

Even after changing the type of these variables, I was still getting the error message. Eventually I tracked it down to one specific query in the data module, an 'invisible' query that has several fields defined as BCDs. Changing these was very difficult but eventually I succeeded. But was that the end of my problems? No - first there was TMemoField then TSmallintField. Fortunately it was easy to overcome these problems by directly editing the appropriate DFM file.

Then when I thought that I had a clean compilation and no run time errors, Windows' Access Control had to stick his ugly head into the process, so I had to spend a frustrating hour or so getting a certificate, saving it into the certificate manager and thence into the Delphi compiler. Fortunately I won't have to do this again, although I may have to copy what is equivalent to a small batch file when I work on another program.

Finally at about 7 pm, after a very long and stressful day, the program compiled and actually ran. I could bring up the list of customers! This may not seem much, but to get this far required fixing and compiling many units and overcoming what can only be described as overhead. Of course, very little on this form works at the moment, but the remaining problems here are relatively easy to fix. 

And once that's done, then I'll have to start the process over again, finding important forms that need to be compiled and then the units that support those forms. The 'DoCustomers' form is used for three different tables and requires 18 different user forms in its 'uses' statement, so completing this form will be an important milestone. Then there is the 'DoDockets' form with about 20 different supporting forms, and the 'DoTables' form with maybe 30 forms. Once these are completed, then 'there only remains' about 40 report forms, but these should be relatively simple to migrate as they are all based on the same template.



This day in blog history:

Blog #Date TitleTags
6701/03/2007Donating bloodHealth, Donating blood, BCC
23601/03/2010More MBAMBA, Economics
33801/03/2011Pre-exam nervesMBA, Randy Newman, Marketing
81501/03/2015Last of the luddites (2)Computers