On 5/19/20 12:59 PM, Martin Frb wrote:
On 19/05/2020 10:42, Joost van der Sluis wrote:
It is basically this class: (see
https://gitlab.freepascal.org/Joost/fpdserver/blob/master/fpdbgvariables.pas)
TDbgVariable = class
private
FName: string;
FValue: string;
FType: string;
FVisibleInScope: Boolean;
FFlags: TStringArray;
FAdditionalInfo: TDbgVariableList;
FInheritedChildren: TDbgVariableList;
FChildren: TDbgVariableList;
published
property Name: string read FName write FName;
property Value: string read FValue write FValue;
property &Type: string read FType write FType;
property VisibleInScope: Boolean read FVisibleInScope write
FVisibleInScope;
property Flags: TStringArray read FFlags write FFlags;
property AdditionalInfo: TDbgVariableList read FAdditionalInfo;
property InheritedChildren: TDbgVariableList read FInheritedChildren;
property Children: TDbgVariableList read FChildren;
end;
Where is that documented? Assuming this is part of the API?
E.g. what goes into Flags/AdditionalInfo?
You misunderstood me. The class above is my own design. The
variable-definition of DAB is even simpler. (As you already found out)
It is not documented, and, to be honest, only name, value and type are
being used now. It is just a rough idea, we have to figure things out.
Btw, for Children (I guess Fields of a struct?) we have TDbgFields. So
maybe that can be replaced? But it affects all debuggers....
They don't have to be fields. It can be anything. To the user it is
presented as something they can collapse/expand. If you want to give a
hint to the GUI how to represent the data, you can set a flag.
At least that's how it is implemented in DAB. I thought it would be a
good idea to add a second 'group of children', the AdditionalInfo. For
example for the character-set of a string. Things like that.
Things like Children should have a Getter, so they can be produced on
demand.
Yep. But I see this structure more as a an interface. A definition about
how the data should be structured.
In DAB they resolve this by setting some reference-id. So instead of the
children, you get an ID. And if you want to have the children, just send
a request with the given Id, and you will receive the children.
Not a real solution for our case, I would think.
Though that creates issues:
- Calling in correct thread
- any data retrieval from the debugger needs to be async. I.e. on
callback. The IDE demands the data, and it will be available in/after a
callback.
However, maybe that can be done in a subclass/wrapper in the
TFpDebugDebugger class. That is were the async is currently handled.
Maybe. I don't really have a solution yet. Maybe the reference-id is not
that bad. (In FPDServer the id is an auto-incremented field. In a map I
store the related info, like the thread-id, callstack-index and such.
When this info is not available anymore, the item is removed from the
map. Seems to work ok)
Regards,
Joost.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
