* * *

Author Topic: evaluate window unusable  (Read 825 times)


  • New member
  • *
  • Posts: 25
evaluate window unusable
« on: October 07, 2017, 04:02:34 pm »

I have been trying to debug a fairly simple program with one form and several Tedits inside groupboxes.

In trying to debug my work I need to use the IDE to examine variable values and component properties. However, the eval window seems very unreliable and confused.

Often it claims that compoment properties do not exist when the doc says they do.

Type TLIST has no component named ITEMS.
Type TLIST has no component named COUNT.

Case in point it is insisting that Tlist does not have a count property and when I try to evaluate it is say "error".

I had similar issues with Tpanel etc etc. 

If the IDE can not evaluate variables for me I'm going to have to print them out in messagebox calls and I may as well be using circa 1980 MS BASIC.

Is this known to be unreliable ?

Thanks for any explanations.
« Last Edit: October 07, 2017, 04:10:03 pm by lazer »


  • Administrator
  • Hero Member
  • *
  • Posts: 4666
    • wiki
Re: evaluate window unusable
« Reply #1 on: October 07, 2017, 04:23:07 pm »
Yes this is a know problem: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Properties

If you use dwarf (project setting / debug) then properties that directly refer to a variable should work:
Code: Pascal  [Select]
  1. property bar: char read FBar

But properties that refer to a function do not work
Code: Pascal  [Select]
  1. [code=pascal]property bar: char read GetBar

In general the debugger can not evaluate functions.

But you can look at the property.
Ofter the getter function looks like
Code: Pascal  [Select]
  1. function GetBar: CHar;
  2. begin
  3.   result := FData.Bar; // refering to FData.FBar
  4. end;

Then you can evaluate FData.Bar.

IIRC with FStringList, many properties refer to the internal FList.


  • Hero Member
  • *****
  • Posts: 2696
Re: evaluate window unusable
« Reply #2 on: October 07, 2017, 04:55:44 pm »
To inspect property values you may find it easier to add LazLogger to your uses clause and insert DebugLn() calls at the critical points (or just use WriteLn() calls, though on Windows this requires {$APPTYPE CONSOLE}).

Perhaps you are used to the superior Delphi debugger. But remember that has been honed over 30 years by professionals paid to work on it every day, and is Windows-specific (the Delphi IDE is Windows-only) and largely written in assembler/C, not Pascal.

Lazarus has been cross-platform from the outset, and its reliance on a third-party debugger (gdb) is an acknowledged weakness. gdb was never designed to debug Pascal, and frankly it is a near miracle that Lazarus developers have manged to get it to work as well as it does outside its preferred C environment. gdb has no concept at all of Pascal properties. Several attempts at a native debugger for FPC/Lazarus are under way, but none has yet reached production quality, and so reliance on gdb persists. I wish I had the skills to help in this endeavour, because for some it is a shortcoming in Lazarus that puts them off entirely.

If you've ever browsed the LCL sources you'll see that the developers themselves use DebugLn() calls regularly, and often leave them in the sources commented out.



Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus