This allows the writer to have access to the names of the log categories, for example.

This is needed, for example, to call CoInitialize/CoUninitialize on a writer background thread that uses COM objects.

When the log is cached, a TjachLogToFMXMemo writer is registered and a call to WriteCachedLog is executed, the memo shows the Cached LOG Write BEGIN and END messages together, followed by all the cached messages.

The expected behavior is to show the BEGIN message, then all the cached messages and the END message afterwards.

A example log shows like this:

2022-03-29 00:22:49:554 00002DBC Info  Cached LOG Write BEGIN ********************
2022-03-29 00:22:49:554 00002DBC Info  Cached LOG Write END **********************
2022-03-28 00:22:48:266 00002DBC Info  [General]Message No. 1
2022-03-28 00:22:48:266 00002DBC Info  [General]Message No. 2
2022-03-28 00:22:48:266 00002DBC Info  [General]Message No. 3
...etc

This allows access to the writer instance on the event handler, which is desirable.

This allows to build user friendly configuration interfaces for the logging system.

Some of the internal objects created during startup are not freed before the application closes, this includes:

• registration of available/created writers
• the list of threads for continuous log generation that are active (the threads are being freed correctly, but the list itself is leaked at the end).

This allows to build user friendly configuration interfaces for the logging system.

To be consistent with other writers.

if UseSeparateThreadToWrite property is set, and you establish a different Verbosity level filter in a writer, the filter doesn't work at all. All debug messages are written to the output.

This is a must to achieve good performance while writing logs to a database connection.

With the current OpenLogChannel/CloseLogChannel approach, the writer would have to cache the log entries data passed as parameters to the write method. It is better to give the writer access to the queue and allow it to work with or cache the entries directly.

If the threshold is reached, a certain number of lines at the beginning must be deleted to allow the control to operate for a while without reaching the threshold at each call.

It may be done adding two properties, one for the threshold and other for the number of lines to delete or to keep in the control.

There are some applications where you need less flexibility to the library.

One is the simple application that doesn't require the topics feature at all.

Other is the application that will always require a topic and you don't want to allow a developer to call the Log functions without defining an explicit topic.

In the middle are the applications that can use and manage both approaches.

Add a base class to inherit to write writers to a database using different connection types.

The error occurs inside the TjachLogWriteCoordinatorThread.Execute method when checking the Writer.IsActive, the address read is 0.

Actually, if both are set to true, the cache mechanism doesn't work, but the messages are directly written using the auxiliary trheads.

When WriteCachedLog is called, the CACHED LOG BEGIN/END messages are written in the context of the calling thread and not using the writer's own threads.

When both are set to true, the messages have to be cached and when WriteCachedLog is called the threads created for that purpose have to do the actual work.

Actually the debug level filter is global and applies to all log topics, but there are sometimes that you want to enable debug messages at different debug levels for different topics.

This filtering will affect at a log instance level, affecting all log destinations (writers).

Actually the debug level filter is global and applies to all log topics, but there are sometimes that you want to enable debug messages at different debug levels for different topics for a specific destination (writer).

This filtering will affect at a destination level, affecting only the messages processed by the specific writer instance.

This is to allow all the units using the ujachLogMgr unit to log it's messages during program finalization and avoid AV's related to using the already freed instance.

The log to disk loses exactly one character when the data has no spaces and the remaining of the line is just one character greater than the maximum line length of the disk writer.

Take this example:

  DiskLogger.MaxLineSize := 39;
  jachLog.LogInfo(' 40 1234567890123456789012345678901234567890');
  jachLog.LogInfo('1234567890123456789012345678901234567890');
  jachLog.LogInfo(' 41 12345678901234567890123456789012345678901');
  jachLog.LogInfo('12345678901234567890123456789012345678901');
  jachLog.LogInfo(' 50 1234567890123456789012345678901234567890');
  jachLog.LogInfo('12345678901234567890123456789012345678901234567890');

The resulting log is:

2023-02-27 14:19:38:616 00000D00 Info   40
                                       123456789012345678901234567890123456789
2023-02-27 14:19:38:616 00000D00 Info  123456789012345678901234567890123456789
2023-02-27 14:19:38:616 00000D00 Info   41
                                       123456789012345678901234567890123456789
                                       01
2023-02-27 14:19:38:616 00000D00 Info  123456789012345678901234567890123456789
                                       01
2023-02-27 14:19:38:632 00000D00 Info   50
                                       123456789012345678901234567890123456789
                                       01234567890
2023-02-27 14:19:38:632 00000D00 Info  123456789012345678901234567890123456789
                                       01234567890

The messages including exactly 40 consecutive chars in the message lost the last '0' char. All other messages are correct.

It's better if the control always scrolls down when new messages arrive.