Relative date fields

Our old pre-Priority ERP system had what I considered to be extreme flexibility with regard to date fields. One could enter a date (e.g. 07/07/2021) but one could also enter a relative date such as -7 or +7; in the first case, this would translate to 01/07/2021 and the second would be 13/07/2021 (or maybe 14 - I don't remember). Priority has a different kind of flexibility: when a date field appears in data entry mode, one has to enter a date, although there is auto-completion: no need to write the year if the date is in "this year", similarly no need for a month if the date is "this month". There is no need for the slashes but one has to enter two digits for the day, so it would be enough to enter "07" which would be replaced by 07/07/2021 (actually, there's another short cut for "today" - "+". Pressing "+" again gives tomorrow and so on). But when a date field appears in data retrieval mode, one can either enter a date as above, or choose from a predefined list containing values like "Beginning of the current month", "Beginning of the previous month", "End of the previous month" or even "End of the next month". Over the years, I have become to appreciate these predefined values as it makes defining saved queries such as "retrieve all orders entered in the previous month" very simple.

In the OP's management program (my private quasi-ERP system), I figured out a way to implement auto-completion a few years ago, even though I suspect that the users haven't cottoned on yet. With the advent of saved queries,  the right side of my brain has quietly been contemplating how to implement relative dates. The pieces fell into place a few days ago; originally I had considered having a database table ("when the only tool one has is a DB manager, every problem can be solved with another table") containing the name of the relative date as well as a formula for calculating that date, but the formula part had me stumped. I realised that it would be much easier to define a new component, based on a combo box, into which would be loaded the various relative dates; the combo box would have a GetData method that could either auto-complete a date entered manually or could calculate the real date from the relative date.

This is an aspect of Delphi that I haven't used very much (defining new components) but it turned out to be much easier than expected. I also discovered that changing the component (adding things that I didn't think of at first, like font or width) could be done simply without the need to reinstall the component into the user library.

The code required to check the value of the combo box has changed from what it used to be, but now that I've figured it out, I can use it wherever I need to use a TRelativeDate.

All of the above lead me to consider whether I could develop a TSavedQueryPanel: a panel that includes a list box containing the names of saved queries, along with the three speed buttons. The panel would have methods for loading the saved queries, adding a saved query, executing a saved query, updating a saved query and deleting a saved query. If I'm not familiar with defining new components, then I am doubly unfamiliar with developing new container components (i.e. a component that contains within more components - hence the panel). But there is a problem with coupling - all of the methods mentioned at the beginning of this paragraph require access to a database and this would be extremely difficult to generalise. I shall pass this problem over to my right brain who is currently unemployed.