{@nnn}    // Left alignment
{nnn@}    // Right alignment
{@nnn@}   // Center

{@nnn} - Left alignment

Instructs HLParser that "what follows" up to the next tag or character has to be written at position nnn in that line. It provides an easy way to put strings at a precise location.

CARE:

• The first character after the closing bracket of the "@" tag will become the nnn-th character of the line (not nnn+1 one).
• Don't put spaces between '@' and the 'nnn' value.

The "nnn" value must be positive. It is considered by the parser to be an integer.

Examples of use:

HLog.Add('{@10}Exiting functionXXX.');
// Will ouptput 9 spaces, then the string "Exiting functionXXX."
// Thus writting the first letter("E") at position 10

HLog.Add('{@10}Exiting functionXXX :{@35}{hms}');
// Will ouptput 9 spaces, the string "Exiting functionXXX:", 
// some more spaces to reach the position 34 and
// the parsed value of the {hms} tag           
// {hms} parsed value will start at column 35

There is NO space between {@35} and {hms}. HLog writes spaces as found in the HLog.Add parameters.
Anything between tags is considered to be a string and is part of the parsed result.

{nnn@} - Right alignment

Right alignment to a position will be obtained by reversing the position of the '@'character:

HLog.Add('{25@}Exiting functionXXX.');
-> writes "Exiting functionXXX." at position (25 - length('Exiting functionXXX.')).

{@nnn@} - Center

Centering is obtained by using two "@", one before and one after the requested length.

"What follows" the tag is centered in a string of lenght will nnn. It will start at the current position of this line. If an odd number of spaces has to be added, the extra space will be added after the string to center.

The important point is that what has to be centerd isn't centered between the end of the previous string, and the first non-blank character of the next one, but exclusively related to the length you pass between the two "@", that is considered to be the full length of that field.

The examples illustrates that behaviour:

hLog.Add('{ruler+}');
hLog.Add('Left part{@25@}Middle string{}End of the line');

results in

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
Left part      Middle string      End of the line

But

hLog.Add('{ruler+}');
hLog.Add('Left part{@25@}Middle string{@50}End of the line');

results in

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
Left part      Middle string                     End of the line

The difference between the two outputs is that the second one adds spaces before the last part of the line, to write it at position 50, using the {@50} tag. But these extra spaces are not taken into account when centering.
You may also note the use of an empty tag "{}" in the first example to signal the end of one part of the line and the start of a new one. If the empty tag is omitted, HLogParser tries to center the whole string "Middle string End of the line" in 25 characters and writes with only one leading blank it as it is not possible to center a 29 character string in a 25 character field.
For clarity: A leading space is allways added when two strings/tags translations may override each other, for clarity.

Instructs HLParser to pad the string with characters 'X' up to position nnn.

hLog.Add('{ruler+}');
HLog.Add('Exiting function{*25.}: ' + 'What you want');

looks like

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
Exiting function.........: What you want

And basically,

HLog.Add('{*20.}');    // Will output 20 dots at the beginning of the line:
....................

Some combinations of tags:

hLog.Add('{ruler+}');
HLog.Add('{@5}=> Entering function{*35.}: ' + SomeFunctionName + '{60@}({HMS}-{GTC})''{@5}=> Exiting{*35.}: '{60@}({GTC})');

Result:

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
    => Entering function...............: MyFunction        (19:21:35-5164171)
    => Exiting.........................: MyFunction        (5173546)

The character at postion 60 is the first openning (left) parenthesis. Remember that tags action range is "up to the next tag or string". In this case, the next tag is the {HMS} one, and then, the {@60} visibility starts and stops with the preceding left parenthesis.
This can be changed: Enlarging the visibility range of @ tags.

It's not possible to step backwards and overwrite existing parts of a string. A tag is ignored if it tries to move the cursor to the left.
An extra space is added before the start of the new string, to preserve the clarity of what is logged:

hLog.Add('{ruler+}');
HLog.Add('Exiting{*25.}: ' + SomeFunctionName + '{@30}({GTC})');

results in

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
Exiting..................: MyFunction (12554877)

instead of

Exiting function.........: MyF(12554877)

Right alignment of blocks of string/tags need a special workaround as "@" formatting tags works on what follows "up to next part" of the final string (what follows a tag or a string). This is provided through another tag: {&}.
{&} tags works as pair. They instruct hlParser to consider everything between two {&} tags as a single string, before working on a @ tag.
Example:

hLog.Add('{ruler+}');
HLog.Add('{@5}-> Entering function{*25.}: ' + SomeFuncName + '{60@}{&}({HMS}-{GTC}){&}');
HLog.Add('{@5}-> Exiting{*25.}: ' + SomeFuncName + '{60@}{&}({GTC}){&}');

In the last line above {&} tags are needed again because otherwise only the openning parenthesis would be at position 60.
But we want the whole block of three parts "(", GTC value and ")" to be right aligned at position 60.

Result now:

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
    -> Entering function.....: MyFunction (19:31:09-5738500)
    -> Exiting...............: MyFunction          (5758312)

Grouping parts of strings with {&} tags can be used only with right or center tags ({nn@} and {@nn@}). Using them with left alignment tags is ignored.

Please note also that {@} tags embeded BETWEEN two paired {&} tags are ignored too.

In order to interpret {@nnn} tags correctly (ie. "whenever possible but without overriding other values") the parser works in two passes:
-> The first one converts all tags but {@} and {&} ones.
-> The second one works on positionning (after checking for {&} blocks).

So, chaining two positionning tags in the form {@nnn}{*NNNx} would give unwanted results:
During the first pass, the {*NNNx} would override the {@nnn} temporary stored value, to "complete" it with the specified character, up to the specified length.
An error will be written as the {@nnn} tag is no longer valid.

A workaround to this is simply to add an empty tag between the {@nnn} and the {*NNNx} tags.

Examples:

hLog.Add('{ruler+}');
hLog.Add('{@10}{*5>}Strings to be written'');  // Writes an error:

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
#HLTag(@10>>) Strings to be written

Workaround:

HLog.Add('{@10}{}{*5>}Strings to be written');
         >>>>>Strings to be written

Remark: The contrary is not true.

hLog.Add('{ruler+}');
HLog.Add('{*5>}{@30}Strings to be written')    // is ok

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
>>>>>                        Strings to be written

"String To be written" starts at the wanted byte position of 30

The parser will add a carriage return / line feed pair each time it meets this tag.

hLog.Add('{ruler+}');procedure TForm1.Button8Click(Sender: TObject);
var i: real;
    s: String;
begin
  Randomize;
  i := Random;
  s := TimeToStr(now);
  hLog.Add('{ruler+}');
  hLog.Add(vsNone,['Here are some datas to output exactly like I want {/}',
                   '{@15}This one is number{@40}: ',1, '{/}','{@15}and this one is number{@40}: ',2,'{/}',
                   '{@15}the third one is {@40}: ',3, '{/}',
                   '{/}You can see the whole bunch mixes integers, real, and strings (including tags) whithout problems...','{/}',
                   '{/}By the way, "i" value is{@40}: ', i, '{/}',
                   'and the time part of "now()" function (',now,') translates to : ',s ]);
end;

    5    10   15   20   25   30   35   40   45   50   55   60   65   70   75   80
....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|....|
Here are some datas to output exactly like I want 
              This one is number       : 1
              and this one is number   : 2
              the third one is         : 3

You can see the whole bunch mixes integers, real, and strings (including tags) whithout problems...

By the way, "i" value is               : 0,990934341913089
and the time part of "now()" function (38060,9705908102) translates to : 23:17:39

{/} tags can be either part of a string or can be used standalone with the same result.

In order to write brackets as strings, simply enclose them between brackets.

hLog.Add('The tag {{}hms{}} is now worth {hms}');

The tag {hms} is now worth 21:12:42