Monday, October 21, 2024

More blog manager tricks

I added a graphing unit to the blog manager program; this is almost the same as the unit in the Management program, but with a few small adaptations. The first is concerned with how the data is passed to the unit; in the Management program, a query is passed, whereas in the Blog manager, the data is stored in a new instance of the temp table so the instance pointer is passed to the graphing unit that also disposes of the instance when the form is closed.

In this program, I want the graph to be sorted by ascending values (at the moment, either number of blogs per tag in a given period, or number of blogs per month) - this is something that I learned today. This is achieved by the following three lines - note that the first two access YValues whereas the third accesses XValues.

series1.YValues.Order:= LoAscending; series1.YValues.sort; series1.XValues.fillsequence;

There's another problem with the Blog manager: at the moment, two separate databases can be accessed by the program. This means that ideally the string that holds the location of the database to be accessed should be empty when the program starts. But for development purposes, I need that the location string not be empty; not only that, the location on my development computer is not the same as on my laptop. When the program starts, it automatically accesses the database at the location stored within the program, but this location does not exist and so the program crashes.

I've been dealing with this problem since I added the second database. I had a solution, but unfortunately it got lost presumably when restoring the program from backup yesterday (I had problems with the dimmer form). After thinking about it for a while, I implemented a different solution from whatever solution I might have had previously (I think that this was dependent on the order of form creation in the project's dpr form). I am documenting here in case it gets lost again, or in case I need it for another program.

procedure TDm.DataModuleCreate(Sender: TObject); begin // prevent the compile time definition causing a problem with sqlconnection1 do begin close; params.values['database']:= ''; end; end;

Like every other problem, it looks so simple when looking at it in retrospect. 

[Edit from a day later: unfortunately, the code presented above for solving the db problem does not work. I've tried putting the 'about' form (by which the database is chosen) at the beginning of the dpr unit, prior to any form being created, then having the datamodule created then the main form. This still does not work, so at the moment I have cleared the value of the database string. I wonder whether I can pass the chosen database name during the creation of the datamodule.]



This day in history:

Blog #
Date
TitleTags
5821/10/2006
Busy morningProgramming, Randy Newman, Paul Simon
64221/10/2013
Paul KleePersonal, Bristol Grammar School
108421/10/2017
Sumptuous Saturday Seven - baked hake with potatoes and vegetablesCooking
168121/10/2023
Seventh chordsMusic theory

No comments: