[Lazarus] Callstack parameters

[Martin]

On 08/03/2012 22:04, Hans-Peter Diettrich wrote:
> Martin schrieb:
>> On 08/03/2012 19:57, Hans-Peter Diettrich wrote:
>>> Is it possible to disable the display of object members in the 
>>> parameter list?
>>>
>>> Currently an object reference hides all following parameters :-(
>>
>> Can you give an example?
>> If I pass an object (instance of a class), I just see the address.
>
> Right, it's not object references. But e.g. a "var message: TLMessage" 
> parameter, as found in message handlers, is expanded.
Ok, I can see that.


At the moment their would only be simple (based on parsing, the textual 
representation) methods. That means the debugger(IDE) is not (and will 
not be aware)  what type (e.g. record) the data has. Evaluating that 
type info would slow down the callstack (really slow it down)

But things can be done based on text.
E.g each argument could be cut after max 15 char, or the ": {" could be 
found. (Though that needs to be pascalized...)

Of course not everyone wants it cut. So an option (and probably one that 
can be saved) needs to be introduced.
So some of the work is in the user interface.

It wont have a high priority on my list right now.

But you can add a quickfix for your own IDE

1) debugger\callstackdlg.pp  called for display and copy to clipboard

function TCallStackDlg.GetFunction(const Entry: TCallStackEntry): string;
begin
   Result := Entry.GetFunctionWithArg;
end;

2) debugger\debugger.pp line 9005
   This is where the arguments are assembled
   So it will be easy to "cut them down"
   If then a parameter is added, and can be toggled from UI....
   (also used by thread window)

function TCallStackEntry.GetFunctionWithArg: String;
var
   S: String;
   m: Integer;
begin
   S := '';
   for m := 0 to ArgumentCount - 1 do
   begin
     if S <> '' then
       S := S + ', ';
     S := S + ArgumentValues[m];
   end;
   if S <> '' then
     S := '(' + S + ')';
   Result := FunctionName + S;
end;





>
>>> BTW: can the parameter column be extended automatically to the right 
>>> margin of the window?
>>
>> In trunk you can resize them and then the size will be remembered. 
>> (unless you use docking, I do not know, if the docking mgr saves the 
>> column widths)
>
> I don't see how docking should affect column widths, the columns are 
> not dockable. The form width is restored, but the column widths are 
> reset to their defaults. This applies to all debug windows :-(

Column widths are saved as part of the window layout.
They often only make sense for the window dimensions they were set for.
So like windows they can be set to
- restore last value
- fixed user set value

Docking seems to have abandoned the existing framework. Despite many 
values would to me still seem use able. Every window still needs to 
store its pos/size if it is undocked.(That value should probably be 
saved even if currently docked / same as it should be stored for a 
maximized window)

Anyway, I have not spent enough time on the subject to argue the matter. 
I can be very wrong, and I acknowledge the work that went into docking.

Unfortunately it means storing column size has still to be implemented 
for docked IDEs.

Its another point I have not yet allocated a time slot for....

>
>> Autosize would be an option, but only if user switchable. Otherwise 
>> it either:
>> - resets the user given size. (which may not be desired if the column 
>> size was made bigger than the space avail, so that a scrollbar is shown
>> - it needs some "smartness" (only do it, if column is sized smaller).
>
> Proper autosize is simple, based on a property of the columns, e.g. 
> Width<0, so that a marked column will use the space left by the other 
> columns. When the minimum column sizes don't fit into the control, 
> scrollbars can be shown.

It is not about the ability to store this.

As a user I can not resize the column to -1. So there must be another 
user selectable option. Also AutoSize is content based, remaining window 
is yet another option.

Configuration of the debugger windows, is a big outstanding issue.
I for example would like to be able to set my own default for how many 
lines of stack frames are shown ...

So when I start on all those options, I will try to remember column widths.

But yet another point I have not yet allocated a time slot for....


--------
Right now, I'll spent some time on a few SynEdit tasks.
Then I have to look at all the things I want to do on the debugger, and 
decide an order for them.

For some of the issues above there may be ways to get result with 
minimal effort. But I can't make any promises on that now.