Regarding the issue of observing values during debugging

[yinhuajian]

For example, when I want to append data to the database, the code is as follows: 
`qryAppend.FieldByName('F1').AsString := qry1.FieldByName('F1').AsString;` 
I tried setting a breakpoint on this line to observe the value of `qry1.FieldByName('F1').AsString`. However, when I hover the mouse over it, I cannot see the value. I also attempted to use Ctrl+F5 to add a watch window or Ctrl+F7 to open the evaluate/modify window, but none of these methods allowed me to observe the value during debugging. Currently, the only way I can observe the value is by assigning it to a variable, such as `str := qry1.FieldByName('F1').AsString;`. I find this very inconvenient. Is there a better way to easily observe values during debugging?

[Martin_fr]

Is FieldByName a function or a property?

1) properties with getter

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

1. property Foo: TSomeThing read GetBySomeMethod;

For those the compiler does not generate debug info. So they can not be inspected. There is a bug report to add that to the compiler. But currently I have no feedback from the compiler team when that may happen (once it has happen, it then also needs to be added to the debugger).

It may (sometimes) be possible to call the function "GetBySomeMethod" from the debugger / see below.

2) Function
For most (but again, not all) functions the compiler will add info on how to call them.

It then depends on what your debugger setup is. You may be able to call them and see the return value. (but calling them will execute them, and may have side effect / change the state of your app / but that happens in other IDE/languages too, afaik incl. Delphi)

Tools > Options > Debugger > Backend https://wiki.freepascal.org/Debugger_Setup#Setting_up_the_debugger_backend_for_the_IDE
This will tell you which "Debugger backend" you use. If you are on Windows or Linux, and have an i386 or x86-64 CPU then it should be set to "FpDebug".

Then, and only then, you can call (some/most) functions.
If you are on Mac, or have arm/aarch then unfortunately you can not.

To enable function calling from the debugger
Tools > Options > Debugger > General: CHECK "Allow function calls in watches"
  (if you are on Lazarus 4.n then ignore the "BETA" in the name)

Then add a watch
   FunctionName()

The "()" is important !!! (and if the function needs args, then specify them)
In the watch property check "Allow function calls"

In your case that would be
   qry1.FieldByName('F1')

Which (hopefully / if it works) returns the object, and you can then inspect this.

If you want AsString, and if that is yet another function then it would be
  qry1.FieldByName('F1').AsString()
// not sure if multiple calls will work

If it is a property then it may be
  qry1.FieldByName('F1').GetAsString()


As to if the debugger will actually find the function (if the compiler adds the info about it), that may depend on if you are on Windows, or Linux.

IIRC (but its been a while) on Linux you must have debug info for the unit in which the class with that method is declared.
And IIRC in either case, the function must be used in the app or the compiler may optimize it away.


I haven't tested any of that, I don't currently have any DB app ready to test.

[Martin_fr]

Alternatively you can look through the source. If the value is stored on some private field you can watch this.


About function calling.

If you call a function from the debugger, then everything that function does (in terms of global changes) will stay. And your app will continue with those global changes applied.

As I said, that is pretty much default for any IDE that supports debug with function call (afaik).

So if you call FieldByName and if that creates a connections to the DB, then when your app continues, that connection will still exist.
If you are debugging an erron, because of some later part of the app fails on NOT having a connection, then that error may not happen in your debug session, because you created the connection.

In other words, its the same as when you call it in your app, and store the result in a temp var.

In most cases, that is not an issue, but one should be aware of it.