Hi,

One of my frustrations with the IDE have been when debugging record or class variables. The data is truncated to 255 characters and it's very difficult to find the appropriate variable within the structure. I have now uploaded a patch (http://bugs.freepascal.org/view.php?id=21990) that adds a treeview where each variable within the structure is shown. You can easily scroll down to find the desired variable and nothing gets truncated anymore.

As described in the report, I can imaging though that this patch will be rejected as it would be even better to merge both functionalities by using a propertygrid. However this was a quick hack for a project of mine and it works excellent. Therefore I would not see why not to add it for now.

The patch however brings up the discussion what would be the final solution for this problem. Is a propertygrid appropriate? Is there a native propertygrid for lazarus available? What do others think?

Regards, Darius

I' will look at it in a moment...

- Are you aware of the "inspect" function? (in trunk avail via context menu, on every watch)
- There also is the evaluate window.
- And in trunk (if you instal IProDesgn package) you can inspect via hint, and enter the hint with the mouse.

As for the aim...

I would like watches that have structure, to have a "[+]" sign, and be able to expand in the grid.

Hi Darius,

Darius Blaszyk wrote

One of my frustrations with the IDE have been when debugging record or class variables. The data is truncated to 255 characters and it's very difficult to find the appropriate variable within the structure. I have now uploaded a patch

I have been struggling with the same issue for a while. I tried your patch and love it!! Small and simple, yet very effective.

If this doesn't get accepted, I'll definitely add it to my list of local Lazarus mods.

+1

And perhaps if the list view remembers the "expanded state" of the variable. At the moment it collapses each time a single step in code is performed.

Regards,
Torsten Bonde Christiansen.

The idea is create

There is a better way to display objects than the treeview => the "inspect" window has a nice grid that does this. It also handles events better. The treeview shows ONE event, over several lines....

The inspect window though does need an edit-able input for the displayed value. It should have a dropdown with history (much like the eval window)

---------------
Any way trying to find out a few facts:

- Does everyone know of the "inspect" window? (And that watches have a context menu entry, to display them in the inspect window.
- Why do/would you prefer either of the 2 solutions?

---------------
Assuming the inspect window get's the following features:
- edit able, history dropdown for current value
- option to automatically follow the current selected watch which of the following options is most preferable.

1) As in the patch treeview
2) As in the patch , but using the grid from inspect (keep the inspect window independent)
3) Use the existing inspect window (can be docked) with the "follow current watch" option.

Hi Martin,

Martin wrote

- Does everyone know of the "inspect" window? ?(And that watches have a context menu entry, to display them in the inspect window.

My Lazarus (trunk) is about one month old so maybe this has already been fixed, but here are three immediate problems I experience with the Inspect Window.

1) Grid columns don't auto size to the data even though there is lots of empty space on the right. I have to manually resize the last grid column to see data.
2) Clipping of data. Pretty much the same as the original problem reported here, and which
the treeview patch solves. There is no horizontal scrollbar, so I can't see all my data.
3) Vertical scrolling with the scrollbar doesn't scroll the grid until you release
the mouse button. I can't start to describe how annoying I find such non-tracking
behaviour.

What exactly does the Inspect window do better that the Watches window? As far as I can see the Watches window is superior.

NOTE: I'm not saying the Watches window is perfect, there is still place for improvement - formatting of TDateTime values, and the inclusion of the treeview patch would do wonders. That, with the existing ability to watch multiple variables/objects, pretty much rendering the Inspect window obsolete.

Well thanks for the feedback, very valuable...

1) Grid columns don't auto size to the data even though there is lots of empty space on the right. I have to manually resize the last grid column to see data.

Not yet, but now that there is some feedback, that can be fixed.

2) Clipping of data. Pretty much the same as the original problem reported here, and which the treeview patch solves. There is no horizontal scrollbar, so I can't see all my data.

This is a combination of point 1 and 2? If the column was autosized, then there would be.

Very true.

Never noticed. For me most values fit (numeric, bool, enum). But yes strings, sets , methods need scrolling

What exactly does the Inspect window do better that the Watches window? As far as I can see the Watches window is superior.

The inspect and watches have different purpose...

This is about comparing the treeview and the (fixed) inspect grid

So the questions are (if the grid is fixed):

1) what is the preferred display:
- treeview
- grid
One thing, that I believe should be fixed (but does not have to be a hold back) is that methods use many lines (http://imagebin.org/211658 ) FOnSubstitution uses 10 lines. Imho using 1 (scrollable) line in the grid is much better.

2) If grid
- use current inspect window (and dockmanager, if people want)
- use new grid

Hi,

Martin wrote

The inspect and watches have different purpose...

Which are? Even from my delphi days I never used Inspect, only Watches
- maybe I missed something all these years. :-)

I would still go for the treeview as it could nicely display the hierarchy of properties (if supported). The Object Inspector grid in Lazarus proves the grid fails this point. A standard grid was not enough to display all property values, so the grid had to be extended to support a treeview-like node which you click to expand. Yes I know all Delphi and Lazarus developers should be used to this ideal, but it shows the grid analogy was not good enough to start with.

One thing, that I believe should be fixed (but does not have to be a hold back) is that methods use many lines (http://imagebin.org/211658 ) FOnSubstitution uses 10 lines. Imho using 1 (scrollable) line in the grid is much better.

To be fair, Darius's "parsing" of the debug data was very rudimentary (duping the data into a TStringList), but it kept the code simple and solved the [scrolling and clipping] amount of
code to get a suitable solution to a problem. So this could easily be solved with slightly improved parsing of the debug data.

[I guess this deserves a new message thread]
Now on to another point I was going to raise, and your screenshot confirmed it for me. I know this is not your area of expertise.... But why is the toolbar buttons so butt ugly under GTK2, but pretty and anti-aliased under Windows?
See attached screenshot of how the Watches window looks under GTK2.

Well the inspect, has the same purpose, as the treeview.

As you seem to have missed the treeview, there must be a different between the watches and the inspect/treeview.

Things like that need to be added to either.
- filter or sort by visibility (public, private, ..)
- filter or sort by class

There are many other nice features that can be added...

I don't know, if on the long term displaying the base classes as hierarchy is the best idea.
It would be easily get confusing, if other hierarchical stuff is added (e.g do what the object inspector does and allow expanding properties of Form.Font or other objects)

Right now, yes the treeview looks like it will offer more. But will it on the long term?

So, the inspect grid could have the same nodes in future?

for base classes, "header rows" that span all columns could be added...

Of course, that is very uncertain future. But the treeview does not offer any of that either. And the work will need to be done for the grid anyway, as it is used in the inspect window.

We could use the treeview now (with an option to replace it once the grid actually has advanced).
But if the argument for the treeview is, it's potential to be expanded, then it raises the question: is it likely to happen. And is in worth the potential duplication of work.

Or does the treeview have advantages, as it is (without further additions)?

That i s not an issue. It can be fixed. Parsed data is avail by the debugger (on request).

(duping the data into a TStringList), but it kept the code simple and solved the [scrolling and clipping] amount of code to get a suitable solution to a problem. So this could easily be solved with slightly improved parsing of the debug data.

Scrolling and clipping can be solved on the grid too. (I already committed some changes to scrolling)

So please compare grid and treeview based on
- they both use good parsing
- scroll smooth
- auto expand

Needs a new thread. Does it apply to all toolbars in lazarus? They are just toobuttons. So it's an entre different topic

There also is the option to maintain both, the treeview and the grid. And eventually offer both in the watches and object window.

But that only makes sense, if the treeview will be maintained and all the features being added

I /think/ Inspect window in Delphi (7?) had the ability to modify a variable on the fly (well, in between steps) which (in Delphi, again) if memory serves me well, wasn't possible in Watch window. (may not remember correctly, it was almost 6 years since I used d7 last time) [snip]

L.

After some discussion about the patch in
http://bugs.freepascal.org/view.php?id=21990 the main question to remain was: treeview or grid

The main reason for treeview (as far as I am aware) was/is, that additional future feature may be easier to be implemented. But they are not implemented yet. If someone is indeed picking up work on such features, then we can look at bringing the treeview back in (until the grid can do it too).

For now I have done the following. (r 37259)
- For none structured long values (strings) currently a memo with word-wrap is better(better than treeview or grid)
Allows displaying long text.
Allows copy, copy selection
- Same for memory dumps, until we have a nice viewer for mem dumps
- For structured values:
The plan is still the grid, including extending the grid for sub-nodes Until the grid (or rather the persistent storage system) has at least auto-size columns, the memo is used too, but without word wrap. The data is cleaned up (methods on a single line)

I added the splitter to the persistent storage (not supported by docking) so it's width will be remembered.

I added a tool-button to toggle the entire inspect pane
- the button state is not yet persistent
- the icon is actually the icon for the stand alone inspector window. It would be nice to free it up, so we can have a button to sent a watch to the stand alone inspector win. But I am no gfx expert. If someone has an idea...

Hi, Martin

Thanks, I have tested it, in fact I prefer gird style more than a tree, for simple, light and less flicker, if I want to more info I can call Inspect for it.
But I like to have another feature, "Stay on top" for debug watches dialog and Inspect Debug, because I can inspect more than variable and need to watch it changing step by step.

Thanks a lot

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120518/1a4b64b4/attachment.html>

+1

A button that makes the window stay on top. The Registers window is also begging for this.

Thanks, Ludo

Hi,
the watch dialog is already much better than it used to be (remember the time, it just dumped the entire gdb output in a single line...) so I think there are two other features that are really important for it:

* complete support for dynamical arrays (still shows the wrong length / not all elements, or "No symbol \"length\" in current context." )

* direct memory inspection:
So you can print all bytes from address $123 to $456, or all TRects from @foo[0] to @foo[high(foo)]...
Then, if gdb fails to understand again some types, you can still watch the variables.

Benito

Do you have an example where it shows the wrong length? http://imagebin.org/212839 First thing in the watch is the len (and yes it is a dyn array)

"length" is a function. And function evaluation does not yet work (would be nice to have, but different topic).
Simulating "length" imho is no good. Because if there is a local function of the same name, the simulation still had the default behaviour, and the result would be wrong.
Simulating is also not needed, since len is shown.

About showing the content of dyn arrays. Currently the first 5 entries are shown.

One of the issues here is that the IDE must ask gdb for each entry. This can be a very time consuming process. And since a dynamic array can have thousands of entries, some limit need to apply. ( *** One day this should be made configurable. *** )

If you do want to change your own limit:
debugger\gdbtypeinfo.pp line 2025

   FArrayIndexValueLimit := 5;

For multi dimensional arrays, the nested level have the limit lowered by 3 for each level...

You can change the watch type to memory.
Of course it would be nice to have a better viewer, but with the new "detail pane" (from the patch), it is usable.

Do you have an example where it shows the wrong length?

Always. (but I haven't updated Lazarus in a while, it's still r36797, perhaps it was fixed)
E.g:

program Project1;
{$mode objfpc}{$H+}
uses Classes;
var x: array of TRect;
begin
    setlength(x, 3);
    x[2].Left:= 4;
    writeln;
end.

You can change the watch type to memory.

Nice, there it is. Last time I checked it was disabled...

Although it takes a while to figure out that you have to write own addresses like (0x7fffffffe9c0)^.

Benito

Works here. http://imagebin.org/212843

Though I just remember: I did not yet test it on 64 bit.

Only tested on Intel 32 bit yet (it is after all a new feature)

True, it isn't bade for direct address input. Usually you give it the name of the variable.

Assuming you're on Windows, my 2 cents tip:
http://www.abstractpath.com/powermenu/

Best regards,
Fl?vio

Just thinking about that. How will that behave, with docked windows...

Nice tool.
it makes it stay always on top. I was thinking more about bringing the window to the front when a breakpoint is hit but you can still send it to the background if you want by clicking on another window. Powermenu makes it like a modal window. I should have said "bring to top" instead of "stay on top".

Thanks, Ludo

I dislike to use tools that hook into the Windows, it is make my system unstable.
I still prefer it inside the program (Lazarus IDE).

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120520/8bfbd42f/attachment.html>

Zaher Dirkey wrote

I dislike to use tools that hook into the Windows, it is make my system unstable. I still prefer it inside the program (Lazarus IDE).

It is probably easy to add.

Though I have no idea, what will happen when used with a docking mgr... But that seems to be something the dock-mgr must solve....

Does anyone have a nice 2-state icon for a toolbutton?

Benito van der Zander wrote

> > Do you have an example where it shows the wrong length? Always. (but I haven't updated Lazarus in a while, it's still r36797, perhaps it was fixed)

Please try with r37368

Martin wrote

will happen when used with a docking mgr... But that seems to be something the dock-mgr must solve.

Now i used the dock, still buggy but i like it
In docked this button must be hidden, but while we can dock it, i think not need this button any more.

I am using last revision of Lazarus, FPC 2.6 on Windows XP SP3

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120524/f8ebce88/attachment.html>

After we what a recent rant about over-quoting, may I say, this is underquoted.

Then again having found what I said: (In context of an "stay on top button")

It is probably easy to add. Though I have no idea, what will happen when used with a docking mgr... But that seems to be something the dock-mgr must solve....

I fail to see how your answer relates to my statement, in so far it may be seen as over quoted ;>

I said: I do not know what happens with docking, if we add that "stay on top"
You say: You now use docking.

Ok fine, but since what I said was hypothetical (IF in future), how does your real world, right now situation apply? With or without docking, we do not yet have the button.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120524/8a36045c/attachment.html>

My answer is

In docked this button must be hidden, but while we can dock it, ...

I meant if the form not Docked it effect on form and stay on top, but when docking the form, this button can be disabled or hide it.

i think not need this button any more.

Or, you can ignore this future, because we can use dock manager,

Maybe we can ask dock manager maintainer this feature "stay on top", i meant adding new button to effect stay on top, near to close button in the header of dock.

Best Regards

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120525/2b971fdb/attachment-0001.html>

Maybe we can ask dock manager maintainer this feature "stay on top", i meant adding new button to effect stay on top, near to close button in the header of dock.

In a docked layout the user selects the windows, which are or can be visible at the same time. A "stay on top" option is applicable only to floating windows, or to windows docked into a notebook.

When docked into a notebook, only one tab can be visible at the same time. A "stay on top" window then should only select the according tab once, but must not prevent the user from selecting an different tab later.

DoDi

Sure, but the problem is, implementing it for the actuals windows. Any package, that registers windows with the IDE (incl[uding the windows in the IDE itself, do not know (and should not need to know if there is or is not a docking mgr.

So currently the watches window, would have a toolbutton, and simply set the window to stay on top.

Only that way the docking manager can't interfere with it. Even if it would catch the set "stay on top", it could not hide the button.

So IMHO the IDE interface (which already provides methods to show windows (so the layout can be stored etc) must be extended. It needs a command that makes the window stay on top, and a function to provide the info, if that can be done.

So IMHO the IDE interface (which already provides methods to show windows (so the layout can be stored etc) must be extended. It needs a command that makes the window stay on top, and a function to provide the info, if that can be done.

I've many complaints on the management of the IDE windows, but I gave up hope for a real improvement (refactoring).

As the most important issue I'd expect that *all* layouts are subject to their own layout managers, i.e. *also* the undocked layout should get its own manager. The many occurences of "if IDEDockMaster nil" or the like in the IDE code should be replaced by true OO code.

DoDi

There it works