Multilog

This is a simplified integration of the Multilog's logging system (written in Pascal with Lazarus).

You can read here, an overview of the features \ modifications in this fork compared to the original one: it's generally speaking the same things as below, repeated differently.

Beware: this fork compiles and works. But I'm still in the process of integrating it into a project: so, it's still in alpha version (it will be modified to make it more flexible and allow everyone to write\code its own logging rules in $Log_SQL.txt, etc).

---

Why this "MultiLog"'s fork?

Basically, it's the same as "MultiLog" at 97%.

The only difference is that this is a simplified integration of the logging.
This small transformation is a simplified integration of the logging mechanism, of the logged messages: to summarize, originelle Multilog's TLogger class allows the variation of both, a group of target reasons, and a group of source reasons associated with each message. In the end, the original Multilog's TLogger class logs a message with the intersection of both.
The Class TIntegratedLogger here, uses only one group: the group associated with the message. This group must be set \ modified before the logging call(s).
Each modification of this group, is logged with the character °: so, I can follow where the messages association group is, has been, modified.
Another small change: the Class TFileChannel has been modified to be "thread safe", too. And it can indent the logged events by watching the ESP machine register's variation.

Brief summmary of the processing of "MultiLog":

prerequisites ❶:
The Class TIntegratedLogger has a group of methods to trace a program: methEnterMethod, methExitMethod, methValue, methInfo, methWaring, an so one.
Many methods then... without one: methDebug (there's not a group of methods that carry the methDebug signature) !

prerequisites ❷:
Repeated again, MultiLog is composed of sets of methods (each set has its own signature meth*) to trace a program, WITHOUT the methDebug.

prerequisites ❸:
==> In TIntegratedLogger, there remains only 1 classification group - a dynamic group \ "set of: it is simply the filter that lists the ***effectively purposes***, the reasons (among all the preceding possible) associated with each TIntegratedLogger's logging method considered, explaining why one writes (actually and sub-sequentially) in the log (see TIntegratedLogger.FsetFilterDynamic_ofWhatCanBeEffectivelyLogged field).

Global explanation:

Now, a method - which carries an intrinsic signature named "meth*" - is chosen to log. Let's say a simple method: methInfo, methWarning, methError, ...
For which purpose(s), classification group(s)?
At least, the simplest: lwInfo, or lwWarning, or lwError, or lwDebug. However, there can be several classification groups for the chosen method: (lwInfo, lwDebug), or (lwWarning, lwDebug), or (lwError, lwDebug). Or (lwInfo, lwDebug, lwIPC), or (lwWarning, lwDebug, lwIPC), or (lwError, lwDebug, lwIPC), and so on depending on how you analize things. You can define yours, in multi_user*.inc. Beware: a group like (lwInfo, lwWarning, lwError, lwDebug, lwIPC) seems unclear, for me anymay. It's up to you ^^. That's all there is to anderstand...

Drawn summary...:



                     |
  several TIntegratedLogger's API calls 
          are written in the source:
                     |
                  .../...
FsetFilterDynamic_ofWhatCanBeEffectivelyLogged:= [lwEvents];
        (methEnterMethod)→
        (methValue\@integer)→  .  .  (TChannels; it goes below).  .  .>
        (methExitMethod)→
FsetFilterDynamic_ofWhatCanBeEffectivelyLogged:= [lwEvents,lwDebug];
                  .../...
  (methSubEventBetweenEnterAndExitMethods\@boolean)→
                  .../...
                     |



...the continuation:



each message is multiplexed: it is sent by each existing display channel over time,
on a display medium (TMemo □, TFileText ○,TLogTreeView ▶) where it is displayed:
                                    ------→            ○ + □
                                    |
.  .(TChannels).  .  .>(methValue@integer)--→          □
                                    |
                                    |
                                    |
                                    ------→            ○
                                    |
                                    ------→            ○ + ▶

Here are some screenshots that illustrate the major features (unchanged):

➔ IPC (Inter Processes Communication) between between client programs (with ou without GUI, on the left of the image below), and a server program (on the right) which displays the received messages, sent by the above mentioned client applications:

Other little modifications:

• SQL Exceptions that inherit from EDatabaseError are all logged in their own Log_SQL.txt. Indeed, in an SQL application, the majority of errors are due to bad SQL statements, leading to subsequent normal Exceptions and errors.
You can customize your own SQL Exception retrievals, depending on your own (SQL Classes) hierarchy, which itself often depends on your database driver (SQLdb, IBX, Zeos, ...), in the file getdescriptionof_sql_exception_user.inc.
• The TFileText medium display is 'thread safe' (in the same way that TMemo was made 'thread safe') with a specialized Semaphore named a Critical section of code. It separates the descrition of SQL Exceptions from the others, each group in its own text file.
• TGroupOfForWhatReasonsToLogActually can be written to, read from, a variable in the ini configuration file. This allows to imagine methods to activate - deactivate - a DEBUG mode, at run-time, at the client, for example.
• added possibility, to see the reasons for each logging: such a log line was added for [lwDebug, lwInfo] reasons; such another line was written for [lwError, lwIPC] reasons; the last one is a simple [lwWarning]; etc.
• As previously stated, the text file medium can indent the logged entangled events by watching the ESP machine register's variation. What's for? With linked components in a chain of responsabilities (like TDbGrid<->TDataSource<->TDataSet), wich themselves have chained events inside them, it is sometimes easier to code a single line in all existing events (mentionning the parameters that can be used or even changed there) in order to anderstand the movies of contextual events, and to study where whe have to code what: