Not sure, what "Überwachte Ausdrücke" is in English.Switch your Language-Settings for the IDE to English :-)
*snip* in which you can drag items into by selecting their var-name at runtime in the source or pressing strg + F7.That should be CTRL+F5
So to my question. In my Delphi I could bring my vars there and watch their values.IIRC, the Watch-Window in Lazarus is not as "refined" as you might be used to from Delphi, since it's still a work in progress.
E.g. I have a Radiobox and want to watch its item-index.
I dragged to my watch-window "radiobox1.itemindex".
Usually there is a value of 1, 2 and so on, depending what the user clicked.
In Lazaraus I read "Error member not found".
What can I do?
or in other words: What has changed in this use of the window compard Delphi to Lazarus?
If there would be a debug package, which can make my debugging easier, it would be great to learn its name.
Thank you
Nicole
E.g. I have a Radiobox and want to watch its item-index.
I dragged to my watch-window "radiobox1.itemindex".
Usually there is a value of 1, 2 and so on, depending what the user clicked.
In Lazaraus I read "Error member not found".
What can I do?
or in other words: What has changed in this use of the window compard Delphi to Lazarus?
Does that even compile? (not tested, but a property should not have an address that absolute can use / if it does compile, I would think its a bug in fpc)Couldn't it be possible to include some entries into the debug RTL as debug proxies for TypInfo.GetProp/SetProp and the IDE to use them to call the live getters/setters?
In theorycould work. In practice it likely will not.
GetItemIndex()
Tools > Option > debugger > General: enable function calling
Watch -> Properties: enable function calling.
And then it all depends if fpc wrote the address of the function to the correct part of the debug info.
On Linux, there actually is a small chance that it did.
On Windows, it is most unlikely. (even if the function has blue dots...)
Couldn't it be possible to include some entries into the debug RTL as debug proxies for TypInfo.GetProp/SetProp and the IDE to use them to call the live getters/setters?
Now I'm realizing than my suggestion is possible just for the 'published' props where the full RTTI is present.Couldn't it be possible to include some entries into the debug RTL as debug proxies for TypInfo.GetProp/SetProp and the IDE to use them to call the live getters/setters?
It is being worked on. Well something similar.
- The "function" (that is the getter "GetItemIndex") is already in the debugged app.
- The debugger (FpDebug) already has the ability to call functions like this.
But, there are 2 things missing:
When the debugger looks at a term like "MyRadioGroup.ItemIndex", the debugger knows that "MyRadioGroup" is a "TRadioGroup".
1) The debugger must then have a mapping from "TRadioGroup.ItemIndex" to "TRadioGroup.GetItemIndex".
2) The debugger must be able to know the address of "TRadioGroup.GetItemIndex" (and the data-type expected back)
Both are missing, and being worked on.
*snip*
I'm wondering how it is implemented in Delphi debugger. Does it have such a side-effects? (I don't use Delphi for a decades)
On the second thought, I'm wondering whether is it right to observe properties at all, excluding those which are just aliases for fields. What I mean is a property with a getter/setter is there for it's side effects, and the side effects are achieved by executing code into the 'live' context. That contradicts to the idea of just 'watching' the current state. It probably will change it.
For example, getting/setting a property of a TWinControl may involve the whole message loop and to trigger calls to unexpected parts of the code.
I'm wondering how it is implemented in Delphi debugger. Does it have such a side-effects? (I don't use Delphi for a decades)
Well, at least in Delphi in the early years it did have side effects. I do still remember very well, that I fell for it.... Got burned really good. My app worked fine in the debugger, because watching a property did fix my apps behaviour.
I don't see why it would be different today => I fully expect some watches with function-eval to still have side effects. But lot's of them are side effect free, because the code doesn't alter anything.
How to use them is down for everyone to decide for themself. The feature is on it's way.