<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<blockquote type="cite">1) Events to be more frontend centric.<br>
2) Actions (eval watch) to be triggered by the frontend<br>
3) Representation of an "watch" (Should methods be on the Watch
object, or the Debugger object)<br>
</blockquote>
<br>
=====> 2) Actions (eval watch) to be triggered by the frontend<br>
<br>
The evaluation of a watch is triggered when the frontend attempts to
access it. The backend then gets a call to<br>
TWatchesSupplier.InternalRequestData(AWatchValue: TWatchValue)<br>
for that one watch.<br>
<br>
For all I can see neither gdb, nor Fp backends will evaluate any
watch, unless the frontend asks.<br>
<br>
<br>
=====> 3) Representation of an "watch" (Should methods be on the
Watch object, or the Debugger object)<br>
<br>
You introduced a new method to get a watch value.<br>
Debugger.EvaluateExpression(S, Debugger.GetCurrentFrameID,
FLatestRef, @EvaluateCallback)<br>
<br>
and then in the callback the data is in an object:
TLazDebugExtensionVariable<br>
TLazDebugExtensionVariable has a reference, where the debugger can
store any data it wants: integer or object<br>
<br>
<br>
I am trying to see, what advantage this should bring over the
current system:<br>
<br>
* TIdeWatch / TCurrentWatch<br>
=> those can nicely store all the data a frontend needs to
store with the watch (any options the user did chose).<br>
=> this also stores (as TWatchValue) the result returned from
the debugger.<br>
=> Each frontend can subclass it as it wants.<br>
* The frontend decides when it wants the data. The backend then
receives a single call for this/each watch.<br>
* The backend then send a notification for the frontend, when the
data is there.<br>
<br>
Same flow? Main difference is that the methods to invoke the
evaluation are on the TWatch.<br>
<br>
--------------<br>
So far so good.<br>
- The TWatch class is currently quite big. It might benefit from
some cut down, but that is not related to any of the things you
implemented.<br>
<br>
- An advantage is, that a watch eval can be aborted.<br>
Your concept is to discard unwanted results, but the backend still
spends time on evaluating it. Of course you could add<br>
dbg.AbortEval(reference);<br>
In the end, I prefer to encapsulate this into the TWatch.<br>
<br>
- Watches are stored in a list.<br>
That is needed by the frontend. Because the History wants to know
about the watches.<br>
However, this may not be needed by the backend. That can be
reviewed.<br>
<br>
--------------<br>
Collapsing / Expanding<br>
<br>
Currently watches can only be added by the frontend. That may need
to be changed.<br>
Each watch needs a way to ask the debugger for the TWatchValue data
of its children.<br>
=> For that the Watch could call the backend<br>
dbg.GetChildren(self);<br>
=> The backend would then for each child call<br>
watch.GetChildWatch<br>
and the backend would put the data in.<br>
<br>
Something like that.....<br>
<br>
As for the TWatches list:<br>
The watch window would know, which watches are visible (expanded)
and evaluate them.<br>
For the history, each watch could have a "parent" and/or
"CurrentVisible" field. Or the watch has an "Owner" (the window),
which can be asked.<br>
<br>
<br>
On 14/09/2021 16:11, Joost van der Sluis via lazarus wrote:
<br>
<blockquote type="cite" style="color: #007cff;">The big advantage of
the tree-view, is that you do not evaluate sub-watches, only when
they have to be shown. So only those fields that need to be shown
have to be evaluated by gdb. (It also solves the
endless loop you sometimes have)
<br>
</blockquote>
Well at latest when the debugger is idle, evaluation of watches "not
scrolled in" should start.<br>
So when the user starts scrolling, values can be shown immediately.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>