[SOLVED] How to show source line number on runtime

[PeterX]

Hi all,

I already 've read some threads that deal with the Code Line Number on exception (by assert)
and other ways to show this number.

But isn't it possible to have a function LineNumber()
that can be compiled as Const into my Exe ?


Like for example:

...
ShowMessage( 'I am here:   MyUnit.pas line' +IntToStr( LineNumber));
...

[balazsszekely]

Yes it's possible with the {$I} compiler directive. For more info please read this:  http://www.freepascal.org/docs-html/3.0.0/prog/progsu41.html

[PeterX]

Hello GetMem,

>>  ShowMessage( {$INCLUDE %LINE%});

this works fine fore me !


Thanks a lot !!!

[fabiopesaju]

great.

but this {$INCLUDE %LINE%} returns the line number of the showmessage...

what would be the best idea to capture the number of the line that the error occurs?

1    try
2       i:= 12/0;
3   except
4       showmessage( {$INCLUDE %LINE%} ); //will return 4, not 2
5    end;

[molly]

1    try
2       LineNr := Succ({$I %LINENUM%});
3       i:= 12/0;
4   except
5       WriteLn(LineNr); // will return 3
6    end;

... or use GetLineInfo() or GetLineInfo()

[PeterX]

To not harm a whole string I had to write (for example)

Code: Pascal  [Select][+][-]

1. TempStr:= Str1 +WinCPToUTF8( {$I %line%}) +Str2 +...

If not, the whole thing is no more a UTF8 string .. 

[lucamar]

To not harm a whole string I had to write (for example)

Code: Pascal  [Select][+][-]

1. TempStr:= Str1 +WinCPToUTF8( {$I %line%}) +Str2 +...

If not, the whole thing is no more a UTF8 string .. 

What do you mean? %LINE% returns ... well, a number; and "number" characters are exactly the same no matter what encoding you use (except Wide/UnicodeString, of course): #$30..#$39

In any case you could as well use:
    InToStr({$I %LINENUM%})
which will return, IIRC, a RawByteString.

[Martin_fr]

If you are looking for a way that users can return bug reports to you: http://forum.lazarus-ide.org/index.php/topic,44040.msg309199.html#msg309199

[PeterX]

What do you mean? %LINE% returns ... well, a number; and "number" characters are exactly the same no matter what encoding you use (except Wide/UnicodeString, of course): #$30..#$39

Hm.

I currently have the situation that UTF8 chars are sometimes shown correctly, sometimes not, in a txt file.
And I did not jet find the reason why this happens ..

Code: Pascal  [Select][+][-]

1. Z:\MIDI 2019-03-05\Bekannter Künstler\Queen-WeWillRockYou.mid
2.  

Code: Pascal  [Select][+][-]

1. Z:\MIDI 2019-03-05\Bekannter Künstler\Queen-WeWillRockYou.mid
2.  

As this is written into a TStringList   ( by MyStringlist.add( ... )  )
then into a DEBUG text file  ( by MyStringlist.SaveToFile( ..)  )
I didn't spend much time on this issue jet ..


Edit:  I read in the current DEBUG text file with NotePad++ and it says, Encoding = "ANSI" ..

.. Now I picked an older DEBUG  text file from backup, and NotePad++ says, it's  "UTF8 without BOM"

[lucamar]

It picked my curiosity so I wrote a little test. Esentially this:

Code: Pascal  [Select][+][-]

1. procedure TMainForm.btDoTestClick(Sender: TObject);
2. var
3.   AStr, BStr: AnsiString;
4.   UStr: UTF8String;
5.   A, B, U: TSystemCodePage;
6. begin
7.   AStr := 'Line number: ' + IntToStr({$i %LINENUM%});
8.   BStr := 'Line number: ' + {$i %LINE%};
9.   UStr := 'Line number: ' + {$i %LINE%};
10.   A := StringCodePage(AStr);
11.   B := StringCodePage(BStr);
12.   U := StringCodePage(UStr);
13.   Memo.Clear;
14.   Memo.Lines.Add('AStr    = ''%s''' + LineEnding +
15.                  'AStr CP = %u (%s)' +  LineEnding +
16.                  'BStr    = ''%s''' + LineEnding +
17.                  'BStr CP = %u (%s)' +  LineEnding +
18.                  'UStr    = ''%s''' +  LineEnding +
19.                  'UStr CP = %u (%s)',
20.                  [AStr, A, CodePageToCodePageName(A),
21.                   BStr, B, CodePageToCodePageName(B),
22.                   UStr, U, CodePageToCodePageName(U)]);
23. end;

Result in the attached image.

[PeterX]

Okay, I found one difference to how I write code:

You use "LineEnding",   I (under Windows) use only #13

Probably this is wrong ?   => CRLF, #13#10 ??

and using only #13 trashes my text files ?

[lucamar]

You use "LineEnding",   I (under Windows) use only #13
Probably this is wrong ?   => CRLF, #13#10 ??
and using only #13 trashes my text files ?

It's certainly not a good practice but it shouldn't matter ... at least not much. A modern program should adapt itself to read text files with any of the three common line endings.

Unfortunately, not all programs do so so it's best to use LineEnding and make your program more OS-aware.

Even if your files end up somewhat "mangled" it's, fortunately, trivial to convert text files from one style to another.

One problem you may have by using CR as terminator is that it's the standard for old MacOS so some programs will assume it comes from a Mac and will try to convert the whole text from the Mac CP to the Windows CP and back on saving. That may seriously trash your text, which is yet another reason to use the correct line separator.

[Thaddy]

There's a LineEnding const instead of #13#10, #10 or #13.....Use it....

[PeterX]

Okay, using LineEnding didn't make a difference.  (but a good choice to never use only #13 again ...  )

Code: Pascal  [Select][+][-]

1.       FileReport.Add( 'ä--------------------------------------------------------ä');
2.  

is shown  (in Windows10-Text-Editor)  as

Code: Pascal  [Select][+][-]

1. ä----------------------------------------------------------ä
2.  

Looks like a random thing if the file is read as "ANSI" or "UTF8 without BOM" ... 


EDIT:  Notepad++ 7.1 reads my "file of today" correctly as "UTF8 without BOM"
          but  (in this case)  the Windows10-Text-Editor does not.

[lucamar]

Code: Pascal  [Select][+][-]

1.       FileReport.Add( 'ä--------------------------------------------------------ä');
2.  

is shown  (in Windows10-Text-Editor)  as

Code: Pascal  [Select][+][-]

1. ä----------------------------------------------------------ä
2.  

It's very obviously interpreting it as ANSI. The "Ã" is a dead give-away.

Looks like a random thing if the file is read as "ANSI" or "UTF8 without BOM" ... 
EDIT:  Notepad++ 7.1 reads my "file of today" correctly as "UTF8 without BOM"
          but  (in this case)  the Windows10-Text-Editor does not.

One thing you could do to satisfy those pesky Windows editors is write a BOM to your file. Add it to the very first line, before saving, by using:

Code: Pascal  [Select][+][-]

1. {I'm assuming FileReport is some descendant of TStrings.
2. UTF8ToUTF8BOM() is in unit lconvencoding}
3. FileReport[0] := UTF8ToUTF8BOM(FileReport[0]);